Atlas v0.12 is available! It's significantly faster.
To achieve this it has been refactored to create a local "mini-package" cache and to re-use git repo meta-data.
Here's the results with a "reinstall" (e.g. after doing an update):
Much faster!
The quickest way to update is usually with Nimble since your PATH's are probably already setup:
nimble install "https://github.com/nim-lang/atlas@#31eec78100bae17614bc2b45b4660c08ed47efce"Side note: the package cache design opens up the possibility of packages!
Atlas itself may not be the right place, but after this refactor Atlas can be used as a library to parse and cache package info. The static Nimble parser has been well tested and supports 99%+ of Nimble packages out there even including when defined(macosx): or other similar statements.
static Nimble parser, that's been wanted so long.
Definitely! I tried porting your NSheep project to use Atlas: https://github.com/nim-community/nsheep/pull/2
BTW, Nimble did copy an earlier version of Atlas's static parser. I think it falls back to the VM though since it's less capable on many syntax like when defined(windows):.
Can someone explain what Atlas is used for? What is its use case? When to use nimble and when to use Atlas? Thanks.
Atlas is similar to Nimble to but more focused and simpler. It still manages dependencies for Nim projects using their Nimble files but that's all it does.
It has no test runner or binary builds, etc. It just sets up dependencies. Each project is fully self contained and by default all dependencies are cloned into deps/.
Personally I prefer that style and find Atlas to be more stable and reliable than Nimble since it does one thing. Really it's up to user preference as nimble setup or nimble develop works somewhat similar.
Atlas has also been a source of experimentation that made it back into Nimble like SAT and declarative parser. Though recently Nimble developments like "features" have made it back to Atlas.
PS, in my (not so) humble opinion, what Nim needs is a new project nimble2 that combines the best of both with actual package downloads similar to uv. Nimble is too constrained by historical designs that are too hard to evolve – every change is as likely break two other unrelated things. Meanwhile Atlas is too focused.
For a proper nimble2 that doesn't just paper over Nimble's issues we'd need an actual package registry with historical versions (not just git repo caching). This latest Atlas release adds the ability to use Atlas as a library to parse packages since it has the most advanced static Nimble parser.
I just had a look at the github page for atlas. While atlas.nimble in HEAD shows the version to be 0.12.0, the latest github release is 0.10.1.
So is there going to be an official release soon, or are there going to be further iterations of 0.12.0?
The tags are usually only created with a Nim release. Generally #head is the current latest release. Occasionally I bump the Nimble version in my PRs mostly for ease of communication.
That usually gives a bit of time for testing before a Nim release.
I'm working on a 0.12.1 but it's just cleanup for better usage as a library.
Some packages in the nim standard library assume that the whole Nim installation lives under one parent
Which ones?
Show me how to install nim-skills with aur: https://github.com/planetis-m/skills/
With npm I can do it with one line (across all linux distros + windows + macos, btw):
npx skills add https://github.com/planetis-m/skills/had no problems installing nim via package manager
My problem was not in nim installation, but with nimble flags. When you install nim with aur - it works as should: nim works (compile, run), nimble works (install, uninstall). Until you will try to use --useSystemNim flag with nimble. It worked for me on windows (with nim from scoop package manager), but not on linux (cachyos, archlinux).
Fixed a few more semver things:
https://github.com/nim-lang/atlas/releases/tag/0.14.3I downloaded atlas-linux-amd64.tar.gz and extracted the binary. It reports its version as:
[~/Downloads/Nim/atlas/atlas-linux-amd64]$ ./atlas -v
version: 0.14.3+dirty (sha: d85ba9fb8388da13aa0bfb176d269e840fd7d38a)Any idea where +dirty comes from?
Dirty comes from the git repo having changes. Thanks for pointing it out. I'll have to figure out why it's dirty (or thinks it is).
I believe I came up with a "package repository" solution that solves more issues than hassle! I'm curious what y'all think.
The idea is to extend the packages repo to generate and store releases.json caches, which I've done on my fork at: https://github.com/elcritch/nim-packages/
It runs cron jobs every 6 hours that checks for updates in the whole Nimbleverse: https://github.com/elcritch/nim-packages/actions/runs/26401689583/job/77715262239
The release caches provide valuable information for making something closer to a proper "package manager". It allows skipping a bunch of downloading and parsing steps before your package manager can get the metadata it needs.
With the releases.json available you can solve the SAT problem quickly, or do things use releases on github or others.
The GHA job takes about 7-17 minutes to run. It took me quite a few iterations this weekend to get it to run fast enough, and to reduce the size of the releases.json caches. When combined they only take up about 4.9M (674K with xz). The atlas-packager tries to minimize changes.
Now to some initial results of testing the atlas branch with support for downloading source releases from GitHub on my Sarcophagus package:
- 21.754 seconds – full git-only install
- 13.396 seconds – git + release tarballs + initial packages clone
- 11.088 seconds – git + release tarballs + cached packages repo
- 4.894 seconds – git + cached release tarballs + cached packages repo
This version of atlas uses ~/.atlas/caches/ and ~/.atlas/packages/ while still using Git for repos without GitHub releases and unofficial packages. The best of both: the relatively few Nim packages which have proper GitHub releases also tend to be the slowest to download! E.g. zippy, etc.
IMHO, this provides much of the benefit of a full package repository + custom tarballs but builds on GitHub and other Git forges.
P.S. the atlas-packager can build tarballs for all the packages as well as clone all existing repos. It takes only ~30-45 minutes. With xz compression tarballs for all Nimbleverse packages sits at around ~5 GG. The git repos in --bare mode are also about ~5 GB.
That works also inspired a PR for the actual packages repo that splits up the packages.json into folders, one per package with a package.json. It adds a CLI tool to add/remove packages as well as a regenerate command that combines them into a new packages.json.