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.
It is nice now that Atlas "just works" again. No weird Nimble pkgs corruptions.
We just need to get nimlangserver to understand Atlas deps setup. Last I checked nimlangserver just assumes Nimble.
Updating deps seems to not work properly, likely due to missing some git flags. I'm going to try and get PRs in to fix updates this week.
Atlas version 0.9.5 has been released! @elcritch improved the documenation once again and a number of bugs have been fixed. Atlas is now quite stable, according to himself. :-)
Unfortunately I have no time whatsoever left to try any Nim packages let alone package managers.
Thanks @araq! Atlas has been very useful for me. Installing Nim deps is a breeze even on low powered IoT devices. Unfortunately I still have to deal with tensorflow, but teammates with no Nim experience have been able to jump in.
I wanted to add a note that a couple of the fixes/tweaks make it easy to use a workspace (aka shared deps folder). Here's a tweaked version of the setup from the readme.
Multiple projects can share a single deps folder. It can be located any, including relative to a project.
In this configuration Atlas essentially works in a workspace style. All you need to do is setup an atlas.config in each project pointing to the workspace (aka shared deps folder).
Here's an example to setup a folder ws/ as a workspace simply clone a project into a ws/ folder like:
mkdir ws/ && cd ws/
git clone https://github.com/nim-lang/choosenim
cd choosenim/
atlas --deps:../ --confdir:. init
atlas installNow ws/ contains all the dependencies for choosenim such as zippy, checksums, etc!
This works by creating an atlas.config file in the project directory with the JSON field "deps": "../". Repeat the process for any dependencies you want to develop. Alternatively clone new packages.
It's important to note that all the projects will shared the same versions set by the last atlas install command. You can run atlas install --keepCommits to keep Atlas from changing the commits.
Note: The deps config setting can be relative or absolute. So you could do a global workspace like atlas --deps:~/ws/ --confdir:. init.
For my needs, even though I’m not using many local packages (as the intended use case above), switching to Atlas from just using Nimble was a pleasant experience. Atlas on top of Nimble in terms of usability personally feels quite a bit smoother. Some of the information displayed when Atlas pulls packages (such as various release versions, what all depends on what, etc), while not necessarily directly useful at the moment for my needs, still having that available is nice for when I could possibly use it.
Now if Atlas was ever made to be only for local packages and not pull in dependencies or display as much information as it does, I’d be disappointed. Nimble by itself feels clunky in comparison from primarily a visual standpoint. I’m glad that tools aren’t just being replaced but instead options are being made available that build on what’s already here in a way that feels progressive and well thought out.