Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow locking nim version in nimble.lock #1017

Merged
merged 14 commits into from
Feb 13, 2023
Merged

Conversation

yyoncho
Copy link
Contributor

@yyoncho yyoncho commented Aug 8, 2022

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

Copy link
Collaborator

@dom96 dom96 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fair. Though can you elaborate what will end up in the lock file when nimble lock is called?

Comment on lines 120 to 121
if not pkgInfo.basicInfo.name.isNim:
if dir.len == 0:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: instead of adding another nesting to this if, please just put the condition into one of the existing if statements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, I will have to add one if in the else clause as well. It will be:

if not foo and bar:
  ...
elif not foo
  ...

To me this looks less "clean. Let me know what you think.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh, in that case if you wouldn't mind refactoring it out into its own proc that would be the best of both worlds :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move the whole if dir.len == 0: if statement (its body and the else) into a validatePackageStructure proc, then only call it under the if not pkgInfo.basicInfo.name.isNim:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, will do.

@@ -530,6 +528,9 @@ proc hash*(x: PackageInfo): Hash =
proc getNameAndVersion*(pkgInfo: PackageInfo): string =
&"{pkgInfo.basicInfo.name}@{pkgInfo.basicInfo.version}"

proc isNim*(name: string): bool =
result = name == "nim" or name == "nimrod"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nim hasn't been known by that name in long enough to exclude it IMO

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, will do. I will rename a few functions using nimrod in their name as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nim hasn't been known by that name in long enough to exclude it IMO

I reverted that part - nimrod is used in the tests so I don't think that this PR is the place to go and fix them.

proc getNimrodVersion*(options: Options): Version =
let vOutput = doCmdEx(getNimBin(options).quoteShell & " -v").output
let vOutput = doCmdEx(getNimBin(options) & " -v").output
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you're gonna do that then rename getNimBin to getNimBinQuoted

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively just revert this change, quoteShell is much better closest to doCmdExe to ensure we use it (plus other programs like choosenim might be using getNimBin and won't be expecting quoteShell)

Copy link
Contributor Author

@yyoncho yyoncho Aug 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will revert this refactoring and keep the quoteShell in the caller.

src/nimble.nim Outdated Show resolved Hide resolved
@yyoncho
Copy link
Contributor Author

yyoncho commented Aug 9, 2022

Seems fair. Though can you elaborate what will end up in the lock file when nimble lock is 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"
      }
    }
  }
}

@yyoncho
Copy link
Contributor Author

yyoncho commented Aug 9, 2022

@dom96 please disregard this PR - refer to nim-lang/Nim#20179 (comment)

I have to revisit the implementation.

@dom96
Copy link
Collaborator

dom96 commented Aug 9, 2022

Suggested a solution :)

@yyoncho yyoncho force-pushed the nim-as-dep branch 4 times, most recently from cf302e2 to 045134d Compare August 9, 2022 12:49
@yyoncho
Copy link
Contributor Author

yyoncho commented Aug 9, 2022

@dom96 applied your comments(hopefully I haven't missed anything).

@dom96
Copy link
Collaborator

dom96 commented Aug 10, 2022

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.

@arnetheduck
Copy link

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?

@yyoncho
Copy link
Contributor Author

yyoncho commented Aug 11, 2022

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?

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.

Araq pushed a commit to nim-lang/packages that referenced this pull request Aug 24, 2022
* Rename compiler to nim

- see nim-lang/nimble#1017 and nim-lang/Nim#20179

* Better description of the Nim package

Co-authored-by: zah <[email protected]>
@yyoncho
Copy link
Contributor Author

yyoncho commented Sep 2, 2022

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
Copy link

@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)

@yyoncho yyoncho marked this pull request as draft January 30, 2023 08:18
@yyoncho yyoncho force-pushed the nim-as-dep branch 5 times, most recently from 8041276 to 5f4813a Compare January 30, 2023 09:57
@yyoncho
Copy link
Contributor Author

yyoncho commented Jan 30, 2023

Depends on nim-lang/Nim#21313 and nim-lang/Nim#21314

ire4ever1190 and others added 12 commits February 1, 2023 12:22
This caused the lockfiles to ignore certain dependencies
Removes previous hack that needed to read current nimble file state

This changes the lock file structure, but compaitability shouldn't be affected
Using nimlangserver since that was that project I first noticed it with
Will now investigate other tests
Force yes in tests

Fix tests

Go back to non destructive uninstall for deps
Error says it is due to stdlib but it works a few lines later
- Fixes nim-lang#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. In order that change to work we have to add nim package in nimble
packages repo and also add alias compiler -> nim to avoid breaking backward
compatibility.

Here it is the flow:

``` bash
nimble develop nim
nimble lock
```

After that `nimble install` and `nimble build` commands will use the locked
`nim` version
@yyoncho yyoncho marked this pull request as ready for review February 1, 2023 11:10
@yyoncho
Copy link
Contributor Author

yyoncho commented Feb 1, 2023

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.

@yyoncho yyoncho closed this Feb 13, 2023
@yyoncho yyoncho reopened this Feb 13, 2023
@zah zah merged commit edd6b3e into nim-lang:master Feb 13, 2023
@zah zah mentioned this pull request Feb 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

nimble install doesn't respect newly downloaded packages.json
6 participants