Atlas now supports linking local projects together with the new link command, making local development and dependency sharing much smoother.
Here's how it works:
atlas link ../other-project
When you link a project:
The project structure remains clean and organized:
project/
project.nimble
nim.cfg
deps/
atlas.config
dependency-A/
dependency-B/
other-project.nimble-link # Links to your local project
other-project-dep1.nimble-link # Links to other project's dep
This is part of Atlas's "no magic" philosophy - it simply manages your project.nimble and nim.cfg files, which you can still edit manually if needed. You can check the nimble-link files in your deps/ folder.
Atlas is a Nimble compatible package manager for Nim that does not use a global dependency directory ("--nimblePath").
It is a light-weight alternative to Nimble that does not build Nim code. It merely sets up an environment for the Nim compiler. It does that by managing a nim.cfg file for you which you have full control over.
So, cna I not use Nimble and use Atlas instead? Do I use them both? On Nimble for installing apps and Atlas for development?
I agree @lou15b that a clear purpose is missing.
I've actually added Atlas support to some of my packages but I didn't quite understand what for 😅
So, can I not use Nimble and use Atlas instead? Do I use them both? On Nimble for installing apps and Atlas for development?
Here's my take on the purpose of Atlas: it's for developing multiple packages locally.
Nimble is still the "primary" package manager for Nim. It's also the "officially" supported tool as well. Nimble has been improved quite a lot recently! Actually one improvement was that Atlas's SAT package resolution algorithm was ported to Nimble.
Want to install and use some packages and not mess with it? Just use Nimble.
However due to how Nimble works internally it's more painful to develop multiple packages at once.
You can think of Atlas as focused on "local development first" of multiple projects. By default Nimble uses --nimblePaths magic which remains fairly broken (IMHO) and difficult to debug. Doing a quick edit of a dependency directly in pkgs2 for debugging can affect other unrelated projects and is tricky to revert. While Nimble has the develop command it isn't the standard use case and it can be fiddly. It can affect or break other unrelated projects, etc.
Atlas by contrast clones all dependencies into a project's deps/ folder. Your project directly links to the full git repos for your dependencies so they're easy to edit or modify. Meaning it's simpler to switch some dependency to a development branch for testing. Whereas Nimble might require editing your Nimble file and running several commands to do the same. It's small things, but it adds up.
Really it's up to the use case and what you're doing which is the better tool. You could use either one and ignore the other, or mix and match as I do.
For example I switched back to Atlas for my Figuro and CSSGrid development because it's easier to modify together and then make releases. They share the same git repos for all their deps so it's easy to keep them synchronized while not affecting other projects I may be working on. However, my CI uses Nimble to test both projects still.
I still prefer Nimble for testing other peoples projects, or quick one off projects, etc.
I've actually added Atlas support to some of my packages but I didn't quite understand what for 😅
Overall there shouldn't be anything for package maintainers to do. Others should be able to use your project from either Nimble or Atlas.
For a while it was painful because Atlas and Nimble used different package resolution methods. Now both have moved to using the same SAT code and resolution methods. So they shouldn't need tweaking to get the right packages versions to work between them anymore.
Though I like to move my build commands into a shared config.nims so it's easier to use them with Nimble or Atlas but that won't affect users of a library normally.
Note: Nimble is moving towards using the new deterministic nimble file parser from Atlas as well.
That will take time as it will require some nimble file syntax changes. Package developers should be aware of that. Long term it'll make the package ecosystem better.