- task list or run tasks declared in the project's Nimble file
- build build binaries declared in the project's Nimble file
- tests compile and run in parallel tests matching tests/t*.nim, or selected Nim files
The task command lets you run tasks in your project's Nimble file using just nimscript. E.g. atlas-run tasks buildDynlib.
The tests parallel compilation/running is very helpful for speeding up running many tests and puts those cores on your machine to work. It compiles each test with its own nimcache to avoid the linker race conditions. There's few more helpful options like only printing tests that errored.
Here's and example of running tests:
I wish there was a talk at NimConf that would address the elephant in the room, namely the existence of two competing package managers for Nim.
If I am a new user (or an old user for that matter), which one do I use?
Personally, I'm a Nimble guy. Tried Atlas and it never clicked for me. Could never understand the concepts it introduced. Since Nimble now can manage local deps, global packages, and Nim versions, it's a pretty much killer package manager IMO. But I'm sure Atlas exists for a reason and has its audience.
namely the existence of two competing package managers for Nim.
Lots of languages have multiple PMs. Python, NodeJS, etc. Just as long as they can interoperate it's all good, IMHO.
Personally, I'm a Nimble guy. Tried Atlas and it never clicked for me. Could never understand the concepts it introduced.
It's simpler now than the early versions.
Since Nimble now can manage local deps, global packages, and Nim versions, it's a pretty much killer package manager IMO. But I'm sure Atlas exists for a reason and has its audience.
It can sorta manage global deps. YMMV :P
Nimble unfortunately still has fundamentally broken core for handling (global) packages. No idea if local deps mode works better.
SAT and that works fine. But that just papers over the issues with how Nimble handles scanning and cloning packages, their metadata, etc that's broken. Not to mention it reclones entire repos all the time just to update packages, etc. Makes it hard to work on or fix too.
If Nimble works for you, great. For myself I find that Nimble breaks in too many mysterious ways. Atlas breaks occasionally for me but usually it's easier to figure out why and it's usually explicit about it.
comes with a new atlas-run tool
Why the separate tool instead of additional subcommands?
Lots of languages have multiple PMs. Python, NodeJS, etc. Just as long as they can interoperate it's all good, IMHO.
I'm also of the mind package management can be left to the community and the best product will win out and for those it doesn't satisfy there will be alternatives.
Notably there are two under nim-lang on github but there are actually at least 3 others I'm passively aware of. I think like @elritch mentioned interoperability should be the real concern. Off the top of my head I think the other third-party ones I know of support reading from .nimble files (mostly) and usually some other tool specific configuration files in toml,json etc.
Nimble unfortunately still has fundamentally broken core for handling (global) packages. No idea if local deps mode works better.
I actually use a mix of nimble and atlas... I don't have issues with local deps on nimble and I find global package management heresy (so can't speak to the status quo on that).
---
I'm also more concerned with a package manager that works reliably and as expected vs a package manager that is "fast", so I'm not bothered by full clones or the like.
To the extent that nimble is more reliable for me than others might be a combination of I'm happy to obliterate any directories it creates and start fresh and I exclusively use localdeps and lock files.
Why the separate tool instead of additional subcommands?
Philosophy? @araq preferred a separate tool which is fine by me.
Personally I do like the Git pattern where there's a separate tool but the main atlas invokes it when you do atlas run. But ultimately it's one character different. ¯_(ツ)_/¯