nimble
nimble copied to clipboard
Allow locking nim version in nimble.lock
- Fixes #953
Allow having nim as locked dependency.
- I will add unit tests once we agree on the approach and once nimble related changes in nim are merged (I will link the PR in comment). Ditto for the documentation.
Here it is the flow:
nimble develop nim
nimble lock
After that nimble install and nimble build commands will use the locked
nim version
Seems fair. Though can you elaborate what will end up in the lock file when
nimble lockis called?
Here is what it looks like(I have patched packages.json locally to make that work until we have an installable version in main repo)
{
"version": 1,
"packages": {
"nim": {
"version": "1.7.1",
"vcsRevision": "afc3c24ff713453aea869df0df93e591e9947f24",
"url": "https://github.com/yyoncho/Nim",
"downloadMethod": "git",
"dependencies": [],
"checksums": {
"sha1": "33781958ab4835a413519059a03217ee81e56dc3"
}
}
}
}
@dom96 please disregard this PR - refer to https://github.com/nim-lang/Nim/pull/20179#issuecomment-1209010294
I have to revisit the implementation.
Suggested a solution :)
@dom96 applied your comments(hopefully I haven't missed anything).
Just for reference why I'm not accepting this yet: We need to wait for @Araq to give his approval on the Nim PR. So I would say this PR is blocked on that.
But also would be nice for @zah to take a look.
Here it is the flow:
why is nimble develop needed? nim should simply always be part of the lock file, just like any other dep?
Here it is the flow:
why is
nimble developneeded?nimshould simply always be part of the lock file, just like any other dep?
I don't have a strong preference for that. The idea was to avoid managing nim by accident and having it more explicit. Zah suggestion was to do that with flag, but I did it with nimble develop which will help fixing the version as well.
As per my discussion with @arnetheduck I was trying to add flag to make locking possible with nimble --lock-nim lock but that will download the latest tagged version which does not have the proper package structure.
@arnetheduck I think that this feature should be held on till we tag nim version, WDYT?
@arnetheduck I think that this feature should be held on till we tag nim version, WDYT?
I believe this is the case for any nimble dependency, ie nimble will happily download any random version of anything, depending on what is in the repo at the time and what the user happens to have in their global cache.
I think the two issues can be addressed separately - in particular, I imagine that if an application wants a specific nim version, it would indicate so in its nimble file - until nimble has a proper dep resolver and a nimble update package command that allows updating a particular dependency to a particular version, users can set nim#somehash as their version requirement and it should hopefully force nimble to do the right thing (or die trying)
Rebased on top of https://github.com/nim-lang/nimble/pull/1047
Fails with:
Verifying dependencies for [email protected] /home/runner/work/nimble/nimble/src/nimble.nim(2158) nimble /home/runner/work/nimble/nimble/src/nimble.nim(2111) doAction /home/runner/work/nimble/nimble/src/nimble.nim(1695) lock /home/runner/work/nimble/nimble/src/nimble.nim(1528) validateDevelopDependenciesVersionRanges
Error: Some of the develop mode dependencies are with versions which are not in the required by other package's Nimble file range.
I will take a look, it doesn't fail locally on my side.
Depends on https://github.com/nim-lang/Nim/pull/21313 and https://github.com/nim-lang/Nim/pull/21314
Fails with:
Verifying dependencies for [email protected] /home/runner/work/nimble/nimble/src/nimble.nim(2158) nimble /home/runner/work/nimble/nimble/src/nimble.nim(2111) doAction /home/runner/work/nimble/nimble/src/nimble.nim(1695) lock /home/runner/work/nimble/nimble/src/nimble.nim(1528) validateDevelopDependenciesVersionRanges
Error: Some of the develop mode dependencies are with versions which are not in the required by other package's Nimble file range.
@Araq It is good now.