With Nim v2 just around the corner as a library developer I feel limited by Nimble in my ability to provide excellent libraries.
In this RFC: https://github.com/nim-lang/RFCs/issues/524
I present 3 areas of improvement I feel are important:
More details in the RFC.
There is https://nimble.directory/
Doing better that than is hard because we generate the stdlib documentation statically and it's only updated for a new release.
The end goal is to have something which is consumable into a database.
a local SQLite based "ebook" with RTS5 full text search etc. Would be nice.
Atlas now works well for me except for the fact that pratically every Nimble package out there lies about its "minimal" requirements.
But it's worth a try. For example
mkdir newproject
cd newproject
atlas use malebolgia
# add `import malebolgia` to your example.nim file
nim c example.nim
What package resolution strategy does Atlas use? Does it download all the Nimble files first, then does a version solver? The problem with Nimble we run into again and again is that it starts installing packages and then runs into conflicts with later packages. There is no ahead of time solver.
How does it handle diamond dependency issues?
Does it respect semantic versions? Where foo ^3.3.3 means foo >= 3.3.3 and foo < 4.0.0 and foo ~3.3.3 means foo >= 3.3.3 and foo < 3.4.0?
How are you marketing Atlas? You released it a while ago, but since then, I have heard nothing about it.
It picks the minimum specified version. If there is a conflict, the higher version is used.
How are you marketing Atlas? You released it a while ago, but since then, I have heard nothing about it.
Well I don't and only very recently I understood how things should work. But if you're unhappy with Nimble, it's a much simpler code base and avoids 90% of Nimble's complexity by design (IMO) and I accept patches.