When you are searching for packages for your projects, this categorized list can help you to start.
They could be added to Awesome Nim too.
There was another similar attempt recently, see
https://forum.nim-lang.org/t/5190#32541
Thank you for your effort, but I can not imagine that such an incomplete list can be very helpful.
For example Araq listed the GUI packages recently, I think that were at least 8. You are listing only 3, missing at least nigui and gintro.
It is OK that https://github.com/StefanSalewski/cdt is not contained because it is not yet advertised in nimble package directory, but why ignore https://github.com/StefanSalewski/RTree?
i dont get the point of these categorized lists.
I think such a list is not that bad for newcomers to get an overview what is available.
But no nimble packages should be left out -- if you do not like gtk you can not simple ignore all gtk related GUIs, and if you hate RTrees, or do not know what it is, you can not left it out, it may be important for someone.
Maybe such a list can be created automatically, using the nimble tags. Bonus point would be to note what compiles with Nim 1.0.
It's a wiki, we can edit it.
And it's better if people from the domain actually add the packages they find useful like:
Though I strongly disagree with putting nimbus and blockchain in Finance.
Anyway, I find it complementary from nimble.directory, nimble.directory is good when you know what you are looking for but I suppose many beginners would just want to grok the ecosystem.
I find it complementary from nimble.directory
IMO, If nimble.directory was showing/grouping projects by using tags in packages.json, curated list would be much less needed.
When you decide to take vacations and visit a new country, I hope you take a tourist guide or a map of that new location and don't go at random with only a GPS. A map is not complete but indicates interesting places. Depending on your interest in history or gastronomy, you'll take different maps or guides. What is the point of having a complete historic map, if when you go on site you discover that that you have to find by yourself where is hidden this historic attraction? A map is a curated selection of locations that you can browse and organize your trip.
This list of package is similar to a map. Of course, it is probably biased by my personal interests. I said I didn't considered un-pure Nim packages and let aside many bindings to external libraries. I also considered packages with minimal documentation, as I think that for discovering new package, this feature is important. I hope that like a good map, it shows some strengths and weaknesses of Nim libraries (complementary to Needed libraries).
The taxonomy of packages is not ideal and can be revised and completed. Like @mratsim said, it's in a wiki to be easily changed (I'll use Are we scientists yet to complete it). I probably did some classification errors too: just tell me how to correct them.
A third of Nimble packages are useless because they don't compile out-of-the-box with recent Nim versions, don't have minimal documentation or are abandoned, etc. Google or Nimble are not easy tools for discovering new packages. That does not help promoting Nim to a larger developer base and showing that it is a mature development platform. Why this forum has so many questions from newcomers not finding information in the documentation? Why @Araq proposed to build distributions in order to provide curated libraries? The learning step hasn't so much evolved for years. So even if you don't like them or don't understand the use of them, I hope these lists help newcomers experiment with Nim ecosystem and contribute to it.
Though I strongly disagree with putting nimbus and blockchain in Finance.
Please give me a better class name for them. Is "Blockchain" a good one?
I just opened an issue on the awesome-nim repo about adding a few more collaborators, so that PRs can be merged more quickly.
Instead of depending on external Github repository, I've moved my curated packages list to Nim's wiki: https://github.com/nim-lang/Nim/wiki/Curated-Packages
Now everybody can contribute. No need to wait for PR being merged: you just need to edit the page to improve it!
Thats works!
I have moved RTree from Graphics algorithms to Data structures .
I do not fully understand the sorting in each category, seems to be mostly alphabetical, but not strict, and what is about lower case and upper case?
You wrote about prefering pure packages. Note that wNim and gintro are bindings for example. And high quality bindings may feel like pure Nim libs, so maybe including in the list is OK, maybe mark with (b)?
Maybe you can add category microcontroller/embedded? That one may be not well populated, but is important, and I think there are some candidates.
One more question, may we insert a single packages under multiple categories? I guess it would make sense in rare cases, for example my Delaunay CDT can be grouped under Graphics algorithms or Data structures.
I do not fully understand the sorting in each category, seems to be mostly alphabetical, but not strict, and what is about lower case and upper case?
I didn't follow any order, mostly adding a new link under a category when discovering a new package. When there were too many packages, I tried to refine the category breaking it in sub-categories.
You wrote about prefering pure packages. Note that wNim and gintro are bindings for example. And high quality bindings may feel like pure Nim libs, so maybe including in the list is OK, maybe mark with (b)?
I was not strict on that point and did not sort the packages like the standard lib does:
Nim's library is divided into pure libraries, impure libraries and wrappers.
Pure libraries do not depend on any external *.dll or lib*.so binary while impure libraries do. A wrapper is an impure library that is a very low-level interface to a C library.*
But this definition has been extended to not include package wrapping Web services, as the core of the work is not done by Nim code.
I just wanted to show what can be done with Nim, what a newcomer to the Nim ecosystem can expect to use and where she can create new libraries. I did not want to reproduce nimble list but to produce a list of packages most demonstrative of Nim strengths (and weaknesses).
Yes, you could add a (b) marker or other tag to bindings if you want.
This list is only a starting point for newcomers. Then they have to explore the packages and see if they fit their needs and adopt Nim development.
Maybe you can add category microcontroller/embedded? That one may be not well populated, but is important, and I think there are some candidates.
Everybody can add new categories and sub-categories. Or change the taxonomy of classes, if they feel that's not the best structure.
One more question, may we insert a single packages under multiple categories? I guess it would make sense in rare cases, for example my Delaunay CDT can be grouped under Graphics algorithms or Data structures.
At the beginning, I put the same packages in multiple categories. But later, I used human hyperllinks (i.e. @see Categorie > ... > Sub-Categorie) to refer to complementary packages. Sometimes, it's difficult to know and find which category fits best a package.
Thank you!
I'm the maintainer of the awesome-nim and I'm so tired to maintain this repo.
Awesome-nim is now deprecated in favor of Curated Packages.