Nimble downloads package before checking if the same version is already installed

[samdmarshall]

When performing the nimble install ... command, the order of operations appears to be:

1. download source of package
2. prepare package for install (create a directory for the package with the relevant contents from the source repo)
3. check if package version is installed

where I believe the order of operations should look more like this:

1. get list of installed versions of the package
2. get list of remote versions of package
3. compare if the latest version of the package is already installed

I believe this should be the correct order as it doesn't require the download of a repo of unknown size only for the user to then find out that the latest version is already installed.

Edit: i forgot to include the version of nimble i am currently using:

nimble v0.11.0 compiled at 2020-03-11 21:40:19
git hash: 5bb795a364a431f897c3864186dbe1aa138c85b9

and it was compiled against nim version:

Nim Compiler Version 1.0.6 [Linux: amd64]
Compiled at 2020-01-23
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: 89b39ee8fe271d0e1b75c15a4c6cf82eb9c13aea
active boot switches: -d:release

[genotrance]

I think the reason for this is that Nimble looks at the .nimble file for the version info and you need to download the repo in order to do that. I don't think Nimble just relies on git tags for version info. cc @dom96

[dom96]

Yeah, precisely. Although there is definitely room here to change this. Problem is that there are times when the git tag version doesn't match the .nimble file's version info :)

[genotrance]

My proposal is to drop version from the .nimble file and fully rely on tags. I understand that you'd want to build your software with version embedded but sharing version between Nimble and Nim is only possible by importing from Nim and not the other way.

Further, version is only relevant when packaging and releasing software. The git tag is the correct version - you tag after code is done and build after you tag. This way, when you want to bump your software version to communicate with the world, a tag is sufficient. We also no longer end up with out of sync tags and nimble versions.

For cases like Nim 1.3.5 which isn't really tagged yet and under development, it can be installed with compiler@#head if required. [email protected] is meaningless since it is just a snapshot in time and #head gives you the same thing anyway.

Overall, managing package versioning in tags is sufficient for most. For those who want a dev. version, it can be in Nim code but Nimble doesn't care about that case. Nimble only cares when software is released.

cc @Araq

[samdmarshall]

while i agree that released versions of version controlled software should be tagged, i think relying fully on the implementation details of the particular SCM to handle versioning (instead of using the version property in the nimble package file) is going to be problematic in the long run. the original issue i had was with the fact that the local packages don't get checked first, as that is much cheaper (no network requests), it should be done first to cut down on the complexity of actions nimble needs to perform.

[genotrance]

Even if we did check the local packages first, we have no idea if it is the latest so have to go to the network anyway and cloning is the only way to get the .nimble version.

As such, we do not have a nimble update command so install basically serves as both. If nimble update existed then it's arguable that nimble install should stop if the package is present locally. However, I think @dom96's original intention was that when you are installing a package, you want its latest version installed.

[samdmarshall]

with a centralized package list, like with nimble, you can have the package records/specs/whatever also list the current version. That would require more maintenance for the individual package devs, but would solve the problem of needing to depending on SCM details for versioning information. from my experience working on other dependency managers, this seems like the least complex solution. however, that isn't really the point of this issue; which was to suggest a more efficient sequence of actions - for example: nimble install [email protected] will clone the repo of package foo regardless if version 0.1.1 is already installed locally or not. I understand that if you were to invoke nimble install foo then you would expect the latest to get installed, but that isn't specifically what i'm trying to bring attention to here. There is a lot of potential complexity here, and i think that a dependency manager should try to minimize the amount of complexity as much as possible before it performs any "install" actions.