Hi, Sorry, if there is already a command to update all locally installed nimble packages but I wrote a small nimscript.
import strutils
let (outp, errC) = gorgeEx("nimble list --installed")
if errC != 0:
echo outp
quit(1)
echo "Installed packages:"
echo outp
echo ""
let out_lines = splitLines(outp)
for line in out_lines:
let package = line.split({' '})[0]
echo "Updating " & package
let (outP, errP) = gorgeEx("nimble -y install " & package)
if errP != 0:
echo "Error!"
echo outP
else:
echo "Done\n"
nim e update.nims
I hope it is helpful.
Please let me know if there are problematic sides and if there are better ways.
Thanks @gemath,
These are really nice points to consider.
It is great that nim has nimble, the package manager for nim. Its ability to create a project template and publish is also useful. I believe in the near future we will see much more packages in it.
Saying that I observe an ambiguity on the term "update" for nimble packages. If I understood correctly a package developer registers the package with nim-lang/packages and stores it on github. When someone installs the package, files are downloaded from the github repo. Now, the ambiguity starts here. As I experienced myself too, whenever you ask to install the package, it downlods the files with the latest commit, even if the version numbers declared in the nimble file are same. Thus, two computers with the same package file version may have different files. I think this is undesirable for production quality and code maintainability.
For example, the script I wrote above always gets the latest commit from the git due to -y option. (It gives forced yes to reinstall prompt)
An example:
Prompt: arraymancer 0.5.0 already exists. Overwrite? -> [forced yes] Success: arraymancer installed successfully.
This may also be misleading. Nimble checks the version number but the commits with the same version number may be different. I have a few suggestions:
They are my observations and some humble suggestions. Again, correct me if there are some misinformation.
regarding excluding the compiler and nimble, does nimble update those?
On my system choosenim does, since it is Nim's toolchain manager. Not sure if nimble updating itself as a package is recommended.
As I experienced myself too, whenever you ask to install the package, it downlods the files with the latest commit ...
nimble by default clones/checks out the current state of the default branch of a git repository. Which branch that is is configured by the repo maintainer.
... , even if the version numbers declared in the nimble file are same.
That's fine. nimble's job is keeping dependencies met, not keeping files identical. In the requires directive of a .nimble file, one can specify version ranges (like >3.0), which means that exact control of even what package version is installed is not required and not claimed, let alone control of the exact file revision within a package version. The latter is entirely up to the repo maintainer and in most package versioning schemes there is no rigid connection between the two anyway: introducing a new code convention could change every source file in the default branch without justifying a new package version.
If a specific branch/tag/commit is needed, it can be specified in a requires directive or even as a part of a nimble install command .
I have a few suggestions:
The first two bullet points do not make a lot of sense to me, see above.
Another option is to create a package inventory where packages with assured code freeze for given version number are stored. Nimble then fetches the package from that inventory.
That would make nimble a package manager with a repo, like npm. If we had the manpower to curate official package versions, that could be a plan, but Nim has more pressing problems to throw brains at IMHO.
One useful thing with that approach is that, you can also pack binaries ...
Nim packages are a source-centered ecosystem, so building binaries/libs from source is kind of the point of the whole thing. Not having to wait until some curator has built a binary with the newest dependencies and the best optimization options for my exact platform but just building it from packaged source and dependency information is very nice. If we just want to install binaries, most operating systems have their own/better facilities for that.
On my system choosenim does, since it is Nim's toolchain manager. Not sure if nimble updating itself as a package is recommended.
As fas as I know, nimble does not install itself or nim, so my script does not either. I guess it will not be a problem.
Thanks @gemath for your thoughts. It is true that the priority is to carry Nim to well deserved 1.0 release at the moment but I think at some point not in the very far future, nimble should be improved and rehandled. I guess it is already in the roadmap.
There are guidelines in nimble github page. Maybe, somehow, it may check some conditions before letting the package into the package list. For example, it may enforce to have at least one version tag in the repo and versions strictly increasing
Maybe, the guidelines can be extended so that every package has some standards. (Proper README.md, proper nimble file etc.)
Regarding a package manager with binaries, what I mean by binaries is not the binaries generated by nim, but binaries of a library that is wrapped with nim. The nim code can still be in source code form. But if it can pack the binaries of that library as well, then the nim developer will deal with only the nim code, he/she won't need a different build system or knowledge to build the original library. I know it requires more maintanence and it does not have high priority. But I guess, it may increase ease of use, adoption of the language.
Nim has great potential and I really wish it becomes a mainstream programming language (if not the first). As in the community survey , people would like to see Nim as a product, (Maturity, Reliability, Documentation etc) with all the elements. Nimble is also an important part of the ecosystem and I believe it will improve together with Nim and what is done to it will contribute to Nim as well.
Saying that I observe an ambiguity on the term "update" for nimble packages. If I understood correctly a package developer registers the package with nim-lang/packages and stores it on github. When someone installs the package, files are downloaded from the github repo. Now, the ambiguity starts here. As I experienced myself too, whenever you ask to install the package, it downlods the files with the latest commit, even if the version numbers declared in the nimble file are same. Thus, two computers with the same package file version may have different files. I think this is undesirable for production quality and code maintainability.
That's not how it's supposed to work, and I can't reproduce what you describe. From the nimble docs:
Nimble always fetches and installs the latest version of a package. Note that latest version is defined as the latest tagged version in the Git (or Mercurial) repository, if the package has no tagged versions then the latest commit in the remote repository will be installed. If you already have that version installed, Nimble will ask you whether you wish it to overwrite your local copy.
You can force Nimble to download the latest commit from the package's repo, for example:
$ nimble install nimgame@#head
So by default, Nim will install the latest tagged release, which is not ambiguous. Only if the package doesn't use tags or the user explicitly wants the last commit will be used.
Yes, you are right, I noticed that occurs if the user does not tag the repo too. That's why I updated my post with