The upcoming Nim version will ship with the Atlas "package cloner" tool.
Atlas provides an isolated workspace where you can manage projects and their dependencies effortlessly.
Atlas provides a transparent approach to package management. It manages two important files, project.nimble and nim.cfg, without interfering with any untouched configurations.
Use <url> / <package name>: Clone a package and its dependencies into the _deps directory, making it accessible to your current project. Atlas automatically handles the configuration of the necessary files, such as $project.nimble and nim.cfg, simplifying the import process.
Clone/Update <url> / <package name>: Clone a URL and its dependencies recursively into the workspace. The nim.cfg file is created or patched with the required --path entries.
Search <term term2 term3 ...>: Search the package index packages.json for packages that match the given terms in their description, name, or tags. Also searches github directly because many packages are never registered in packages.json.
Install <proj.nimble>: Use the specified .nimble file to set up the project's dependencies.
UpdateProjects / updateDeps [filter]: Update all projects or dependencies in the workspace that have a matching remote URL based on the provided filter. Updates are only performed when there are no uncommitted changes.
tag <version>: Tag and publish a new version.
Atlas is in the early stages of development. As a result, not all packages are currently compatible with it. Atlas installs the minimal required version of a package. This information is extracted from the Nimble file and is wrong more often than it is correct because nobody checks this. Additionally, Atlas relies on GitHub tags to detect versions, which means that if tags are missing, the proper version cannot be selected.
I fear that most of these questions have no clean solution because Atlas is fundamentally not a build tool. Its only job is to setup a nim.cfg, the Nim compiler should be called manually afterwards.
Atlas relies on GitHub tags to detect versions, which means that if tags are missing, the proper version cannot be selected.
To any library authors https://github.com/beef331/graffiti exists and easily generates git tags for whenever you ticked your nimble file but did not create a git tag(except for if your first commit included a nimble version). So if you do not have git tags I do suggest running that.
It's great that there is more competition with Nimble. I'm glad there is more work in this space. After the compiler, package management is the next most interacted-with thing.
Why did you choose "installs the minimal required version" instead of maximum? We currently assume Nimble will grab a higher version, so we don't test the minimum version at all. GitHub tags are a pain. I wish there was a way around them, but I can't think of a quick solution.
How do you handle situations when dependencies of the project need different versions of the same package? How do you account for something needing .dlls included as well, especially for Windows? How do you manage something like Pixie which includes 200MB of testing data, which isn't necessary to install?
Why did you choose to install into the "_dep" folder instead of, say, just the root project folder?
I like that you support URL package names, maybe all packages should just use URLs.
Will there be some sort of work with the Atlas checker? At least for the Nim important packages.
What Atlas features will you be adding next?
Why did you choose "installs the minimal required version" instead of maximum? We currently assume Nimble will grab a higher version, so we don't test the minimum version at all. GitHub tags are a pain. I wish there was a way around them, but I can't think of a quick solution.
Github tags are better than having to edit a nimble file and then also tagging. The version in the Nimble file is redundancy of the worst kind, it frequently goes out of sync and nobody notices. Minimal version selection makes lockfiles far less important, basically you get reproducible builds for free.
How do you handle situations when dependencies of the project need different versions of the same package?
It installs the higher version of the package and lets the programmer handle the problem himself, on his own. In the future it will rename the older package to package_commit and patch the import statements. But Nimble does not handle that case either, yet we manage.
How do you account for something needing .dlls included as well, especially for Windows?
Due to its simplicity, Atlas supports "foreign" dependencies naturally. You can require "https://.../deps.dlls" and it will end up in your workspace. You can then use a custom task to move the DLLs next to your .exe. Custom tasks are supported but not run automatically.
How do you manage something like Pixie which includes 200MB of testing data, which isn't necessary to install?
By telling Pixie's author he should have this testing data in a separate github repository which is downloaded and used in its CI. ;-)
Or by doing nothing. It's not a big problem: You don't mind this data whenever somebody clones your project manually either.
Why did you choose to install into the "_dep" folder instead of, say, just the root project folder?
It's configurable and the default is not to use a "_deps" folder, the docs could be clearer on this.
What Atlas features will you be adding next?
The ones I need to be able to patch my book to contain atlas --autoWorkspace use pixels
Why did you choose "installs the minimal required version" instead of maximum?
If you have multiple dependencies that require the same package at different versions, the minimum compatible to all can be selected.
Furthermore if a new version introduces breakage, you have time to see it coming before your issue tracker gets invaded by reports. i.e. choosing the minimal version favors stability and the package author opt-in for new features and incremental performance improvement. Choosing the maximum means being more exposed to breakage and full recompilation (if a dependency updates often).
Minimal version selection makes lockfiles far less important, basically you get reproducible builds for free. +1, nice idea.
I believe you're looking for the --global flag:
--global use global workspace in ~/.atlas
atlas --global init
atlas --global use malebolgiaI just want to have my repository where I wish and not necessarily in a workspace
I think you are over complicating things. Here is how I split-it personally :
~/Workspace/ => Atlas workspace for non-specific project. ~/Projects/[Project1] => Atlas workspace specific to project 1 ~/Projects/[Project2] => Atlas workspace specific to project 2 etc...
When I don't know where to put a repo it goes in $HOME/Workspace, if it becomes to big or starts requiring specific dependencies version it moves to its own workspace as ~/Projects/[...] .
Bugs aside (atlas is still young) it's a very simple way to have reproducible, portable workspace without requiring a mono-repo.
You can even change Nim version in a workspace with e.g. atlas env 2.0.8
Well, I have ~/Projects for all my projects, Nim or else. There I clone all my repositories and I'd like to avoid having a nested directory structure if possible, and avoid cluttering ~/Projects with Nim stuff.
So I have ~/Projects/app cloned, and if I can optionally tell it to use ~/Projects/lib that would be perfect, but else I'd prefer having the dependencies I don't touch out of the way inside ~/.Nim or elsewhere.
Can someone look at this issue please: https://github.com/nim-lang/atlas/issues/135
Thanks
Atlas just got its biggest update in a long time, workspaces are gone. Instead everything is now project specific only. This avoid tons of internal complexity and makes the command line application easier to use.
Please take it for a test drive. Unfortunately Atlas remains to be a side project. Use it if you can but don't expect much support. But hey, it's open source and all the hard parts (SAT solver, dependency graph) have been done.
Please take it for a test drive. Unfortunately Atlas remains to be a side project. Use it if you can but don't expect much support. But hey, it's open source and all the hard parts (SAT solver, dependency graph) have been done.
A few bugs have been fixed in the SAT solver and dependency loading since the 0.8.0 version! In particular SerVer works properly. Atlas should be more maintainable now with better unit testing of the core features as well. That said the link feature is new and may need some more options to manage it, but it's been working well for me so far.
Note on the new link command:
### Atlas Link Command: Local Development Made Easy
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.