nimibex - Nimib extensions and experiments 🧪

[pietroppeter]

@moigagoo the other day at nimconf mentioned that some of the examples shown (e.g. mermaid diagrams, image slider, plotly plots) should be available as nimble packages. I feel like probably it is not worth to have a repo for every one of them, instead we could make a new repo (tentative name nimibex, where ex stands for both extensions and experiments, also extras) where we collect those and also simplify the management of nimib core (we could e.g. move nbPython there).

Most details would need to be worked out but probably it could be also a way to start migrating to a nimib organization (see #137, also nimconf slide could be moved there and in time nimib repo itself should land there).

[moigagoo]

My arguments for having a separate repo for each extension are:

1. Labor is distributed among multiple parties. That means the whole system is less dependant on a small number of enthusiasts.
2. It forces Nimib to have a stable open API that is used both by the contributors and the core developers. This is a way to enforce dogfooding and grow new core devs.
3. Extensions can be developed independantly on the core package. This reduces synchronization tax.

I'd also like to tackle some counter arguments:

1. Q: Extension is just a cuple on lines, no need for a separate package. A: Size or line count don't matter for the end user. You want to do an import and use the thing.
2. Q: Extensions are better off being part of the core package. A: This dilutes focus for the core devs and makes life harder for contributors. To get your extension live, you must send a PR to the core package and wait for it to be reviewed, merged, and released. If it's a separate package and a separate repo, you just do your thing and put it online.

[pietroppeter]

Thanks for the input. I am all for other people creating their extensions and creating repos. Thing is, for the extensions that I create, having to maintain multiple repos is more of a hassle than a solution. That's why the extensions I create I would put them in a single repo. Once it is there though I see no reason of not accepting PRs from others, so I guess that it risk of becoming a repo where people would want to put their extension...

On the stability of the api, it might be a bit too early but we will get there.

And on reduction of synchronization tax I agree, that's why I would create another repo nimibex for my extensions to keep it separated from the core stuff.

[pietroppeter]

The counter argument for a repo like nimibex is that some extensions might require new dependencies and I am not sure I would add those dependencies to the big repo. So in principle extension with additional dependencies might end up in a separate repo indeed...

[HugoGranstrom]

I agree with Pietro, it's just unnecessary work to put every single one of the "official" blocks into their own repos. The code required for most of them are really small so there wouldn't be any problems with maintaining it in a single big repo for extensions. And if a particular extension would grow really big, big enough that it would deserve its own repo, then we could do it for that specific part.

And as Pietro said, anyone is free to create their own blocks in their own repos and structure them however they like.

[pietroppeter]

btw we have an emoji/log for nimibex:

🐐

https://en.wikipedia.org/wiki/Ibex

I will probably create this repo directly in the new nimib organization (which is also something that I should start planning).

Initial content:

• mermaid diagrams
• before after image slider with juxtapose
• plotly plots
• vegalite plots
• paramidib?

In principle also nbPython could fit in nimibex, not sure if we would want to move it or not. thoughts @HugoGranstrom?

[HugoGranstrom]

Haha nice 🤣

I will probably create this repo directly in the new nimib organization (which is also something that I should start planning).

Seems like a good opportunity to create the org indeed :D

In principle also nbPython could fit in nimibex, not sure if we would want to move it or not. thoughts @HugoGranstrom?

Yes, I would definitely move it out of nimib 👍

[pietroppeter]

while looking at nimibook/mdbook stuff I ran into this funny project: https://github.com/cognitive-engineering-lab/mdbook-quiz

it allows the user to put interactive quizzes in mdbook. I think this is a cool idea that could be a good fit for a nimibex, so that it can be used both in generic nimib documents but also in nimibook. I think it should be fairly easy to implement with Js blocks (we should expose an api that only deals with data for Q&As).

btw, in this Sunday's nimib speaking hours (see #162) we should also discuss nimibex (ideally on Sunday I would actually want to start creating the organization and nimibex repo, then we will move the others).

[HugoGranstrom]

Me want this! 😋 I have also thought about something along the lines of this, it should be pretty straight forward as you say, and equally easy for users to create their own types of quizzes as well.

I feel like nimibex could explode with awesome things like this 😁

[pietroppeter]

created the repo! https://github.com/nimib-org/nimibex