atlas

I actually prefer atlas (see: https://github.com/nim-lang/atlas) to nimble now, it clones dependencies to to a local `deps/` folder relative to the project. It also supports adding local folders to the nimble path for management (via `atlas link` - see docs here: https://github.com/nim-lang/atlas/blob/master/doc/atlas.md#l...), i.e. you can clone your dependencies yourself via git submodule or a manual git clone To solve your woes, fork and patch the code you need to in order to support pragmas for MSVC. And in atlas, use your fork's git path and if you choose to: submit a PR to the project. You can edit the project locally until something works.

I agree, the code output for Nim with Claude and Gemini as well is pretty good. It misses some Nim idioms but generally does really well. Simple syntax with strong types helps both Nim and F#. I used Claude 4 to generate SIMD versions of signed distance functions for both NEON and SSE2 and it all worked and compiled fine the first time aside from some minor import changes [1]. Gave me an almost 4x increase for many SDFs. I also use Atlas, an alternative package manager for Nim [2], to clone deps into a local folder which lets Cursor grep and search the dependencies to add it to the context as needed. 1: https://github.com/elcritch/sdfy 2: https://github.com/nim-lang/atlas

Good points, background downloads would speed it up. And the language doesn’t have much to do with that. This project looks to be someone just toying around with Rust or their own PM. Props for that, but the headline has extra implications on HN. I recently rewrote a big portion of Atlas [1]. It’s a Nim based dependency manager that clones Nim packages to a `deps/` folder. Initially I was worried about using reference types, etc, for performance reasons. It’s a general habit of mine. Then I remembered that stuff would be negligible compared to the download times and git overhead. Well aside from the SAT solver. 1: https://github.com/nim-lang/atlas