search

nim-lang / nimble

Package manager for the Nim programming language.
Other
1.25k stars 174 forks source link

[Feature] manage nim using nimble #1013

Open yyoncho opened 1 year ago

yyoncho commented 1 year ago

Often it is handy to manage the compiler using nimble. This can improve reproducibility of the builds and make the projects more self contained. I spent some time looking into the code and it seems like one of the ways to achieve that is to do:

  1. Change nim project to allow running nimble install in the Nim project root. This means that we have reimplement the logic in build_all.sh/bat in nimble file(I am not sure if calling the script from the nimble file is an option.)

  2. Change nimble to download and use the nim that is coming from the requires section. I am not sure if managing the compiler feature should be on by default or we should have it behind a flag in the nimble file.

Please share your thoughts

(cc @zah)

dom96 commented 1 year ago

Easiest approach here would be to defer to choosenim. It already knows how to download and install various Nim versions. You could even ask choosenim to return you the path of a particular Nim version without switching to it.

yyoncho commented 1 year ago

Easiest approach here would be to defer to choosenim. It already knows how to download and install various Nim versions. You could even ask choosenim to return you the path of a particular Nim version without switching to it.

Correct me if I am wrong but ATM it seems like choosenim supports only tagged versions, right?

If we go with choosenim, then I believe we can allow "injecting" the path to nim binary from the nimble file, e. g.

proc choosenimPathForVersion(version: string): string =
  ...

...

nimBinaryPath = choosenimPathForVersion("<tag-or-commit>")
dom96 commented 1 year ago

Correct me if I am wrong but ATM it seems like choosenim supports only tagged versions, right?

It supports pretty much everything. You can give it a #commitHash or #branchName or /path/to/nim/dir (note though that for existing paths it assumes Nim is already built).

If we go with choosenim, then I believe we can allow "injecting" the path to nim binary from the nimble file, e. g.

True, that would make it more extensible though I think we might want to move away from relying on nimscript too much.

zah commented 1 year ago

The potential new functionality here is allowing the Nim version to be precisely controlled through the Nimble lock file. When Nim is treated as a regular dependency, there are various benefits that we get for free:

1) Conflicting statements in multiple packages regarding the required Nim version will be detected (similar to every other package).

2) It would be easy for a team to temporarily switch to a patched version of Nim available from a forked repo.

3) The nimble binary would be all you need to get a new developer up to speed with a project.

Basically, if we start packaging the Nim binaries in the compiler package (or a new nim package), the existing nimble run command would already have the desired semantics. The proposal here is to make the integration a bit tighter by allowing other commands such as nimble build to also take advantage of the Nim version pinned in the lockfile (as long as the lockfile is present). There could be an option --use-system-nim that suppresses this behavior to facilitate easier experimentation. Putting the Nim package in develop mode would be another way to experiment with local Nim changes.