laying the foundation for future improvements in Nim version management.
I assume this means that nimble will be the only tool you will need to install since it will be able to download, install and select nim versions without having to compile nim itself?
Correct. Although it will require at least one compilation depending on the platform and Nim version.
Command should be something in these lines: nimble install nim{constraint} when outside of a project dir.
There is a new minor nimble release. Likely the last one in the 0.x. branch. Release notes: https://github.com/nim-lang/nimble/releases/tag/v0.20.0
For those that want to try with the experimental new code path, we are going to switch head soon to be the new default. When --legacy is on, one can still use the old code path, although we are aiming to have full retrocompatibility.
Will the --legacy flag be an option post-1.0.0, or will it be fully deprecated by then?
Also, in the lead up to 1.0.0 release is it worth spending some time triaging the existing 200ish issues?
I imagine there are several things that should probably be addressed prior to a 1.0.0 release and several issues that are outdated or won't be implemented and should be closed.
Could utilize GitHub milestones for organization/tracking of these showstopping issues.
Will the --legacy flag be an option post-1.0.0, or will it be fully deprecated by then?
Yes, it still will be an option. At some point it will be removed though.
Also, in the lead up to 1.0.0 release is it worth spending some time triaging the existing 200ish issues?
Yes, this is part of the plan but a little more down the road, when we implement the missing features. Soon we will be addin an issue on GH to keep track of the work and whats left.
As promised, here is the GH issue to keep track of the progress: https://github.com/nim-lang/nimble/issues/1449
Its slow but we are trying to get it right so we can clean the nimble image. Feedback is more than welcome.
Special mention to
Introduce “prefer” for Nim – Uses the system Nim version if possible, selecting older dependency versions when needed. Example: If system Nim is 2.0 but the latest package B requires 2.2, Nimble will choose an earlier package B that works with 2.0.
Glad to see progress on nimble improvements, keep up the good work!
(I can open issues on the repo, but just jotting down thoughts here while pre-1.0.0)
In terms of nimble image I think we should also look to clean up the interface (CLI and logging).
Minor concern: There is some inconsistent formatting, sometimes messages have a colon sometimes they don't.
Major concern: It's never been intuitive to me that build errors are not immediately surfaced. When a build fails one might see:
Tip: 3 messages have been suppressed, use --verbose to show them.
But even with --verbose we don't see compilation errors.
It may be worthwhile while updating this UI to use an actual logging interface (like std/logging) that can also write to a rolling log file.
In the CLI, some flags take a parameter --parser:declarative|parser some are two separate flags (--ini, --json). And the help is not consistent about where text is wrapped.
Side note: glad we'll no longer get "Warning" for using a feature of nimble (i.e. local mode).