Atlas is a simple package cloner tool that automates some of the workflows and needs for Nim's stdlib evolution.
Atlas is compatible with Nimble in the sense that it supports the Nimble file format.
Atlas uses git commits internally; version requirements are translated to git commits via git show-ref --tags.
Atlas uses URLs internally; Nimble package names are translated to URLs via Nimble's packages.json file.
Atlas does not call the Nim compiler for a build, instead it creates/patches a nim.cfg file for the compiler. For example:
############# begin Atlas config section ##########
--noNimblePath
--path:"../nimx"
--path:"../sdl2/src"
--path:"../opengl/src"
############# end Atlas config section ##########
The version selection is deterministic, it picks up the minimum required version. Thanks to this design, lock files are not required.
Dependencies are neither installed globally, nor locally into the current project. Instead a "workspace" is used. The workspace is the nearest parent directory of the current directory that does not contain a .git subdirectory. Dependencies are managed as siblings, not as children. Dependencies are kept as git repositories.
Thanks to this setup, it's easy to develop multiple projects at the same time.
A project plus its dependencies are stored in a workspace:
$workspace / main project
$workspace / dependency A
$workspace / dependency B
No attempts are being made at keeping directory hygiene inside the workspace, you're supposed to create appropriate $workspace directories at your own leisure.
Atlas supports the following commands:
Clones a URL and all of its dependencies (recursively) into the workspace. Creates or patches a nim.cfg file with the required --path entries.
The <package name> is translated into an URL via packages.json and then clone <url> is performed.
Search the package index packages.json for a package that the given terms in its description (or name or list of tags).
Use the .nimble file to setup the project's dependencies.
Thanks to this design, lock files are not required.
FWIW, lock files solve a slightly different problem, which is to reliably produce the same build even if the source changes - minimal version is really really nice as a strategy (ie ideally nimble would use that too), but it does not prevent changes in the source repo that lead to a different set of versions being chose - merely makes it less probable - this should probably be taken into account, both in the README and future design work.
which is to reliably produce the same build even if the source changes
Please elaborate, in my mind that is dealt with by a git tag on the main project. I mean, you only need to pin the commit of the main project in your build server in order to get a reproducible build.
git tag on the main project
the most critical problem is that git tags are mutable - this is a common way to introduce supply chain attacks (which happen regularly) - this is why a lock files contain a hash of the source code (just like git operates on hashes, not "names" of things - a version number is just a name).
If you only ever use your own code, you can of course abstain from modifying tags, but it's a blocker for any broader use (abstaining only gets you so far..) - ie nowadays it's part of the minimal feature set of a package cloner much like https support in a browser - version tags are the equivalent of sending your password in plain text on a public wifi - it's that bad due to how exploitable it is.
blockchain
hashes exist as a way to solve this class of problems since well before blockchains, if that's what you're referring to - starting with git itself.
The author doesn't have permission to modify tags.
the owners of the org still do, as does anyone that hacked the login of any of the owners of the org - you've now just created a juicy target for the hackers to go after.
It's simple to come up with schemes that seem simple - most of them will be trivial to get around as well.
indeed - with the hashes in place, atlas instantly becomes a very attractive tool - minimal versioning, no script execution, lots of things to like.
it's critical though that the hashes that the tool chooses get committed to the repo so that when I clone your repo, I don't have to re-run the version/tag-based resolver.
Well atlas is a tiny tool, we can add support for an alternative to the existing .nimble file that is required to exist when you use e.g. atlas --pin (reproducible build). But if we depart from the .nimble file we might as well do it right and come up with some solution that allows for cross language dependencies.
It should be easy for a Nim package to depend on Godot or Unreal Engine, it should not matter that these are written not in Nim, the dependency analyser can easily work regardless.
Can Mercurial support be added to Atlas too?
Definitely. PRs are welcome.