Cannot install Nim v0.19.2

[braunse]

I tried but failed to install Nim v0.19.2:

$ asdf install nim v0.19.2
Cloning into '/home/..../.asdf/installs/nim/v0.19.2'...
remote: Enumerating objects: 2745, done.
remote: Counting objects: 100% (2745/2745), done.
remote: Compressing objects: 100% (2528/2528), done.
remote: Total 2745 (delta 68), reused 1394 (delta 51), pack-reused 0
Receiving objects: 100% (2745/2745), 3.74 MiB | 3.97 MiB/s, done.
Resolving deltas: 100% (68/68), done.
Note: checking out '7beea1642ddf7845a9a0034c7a93ccbe15894c36'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

Cloning into 'csources'...
warning: Could not find remote branch v0.19.2 to clone.
fatal: Remote branch v0.19.2 not found in upstream origin
/home/..../.asdf/plugins/nim/bin/install: line 11: cd: csources: No such file or directory

Indeed, the csources repository does not contain a v0.19.2 tag or branch at the moment: https://github.com/nim-lang/csources/tree/v0.19.2 -> Error 404

The latest csources tag is v0.19.0: https://github.com/nim-lang/csources/tree/v0.19.2 -> Exists

[rfrancis]

Yeah, it's a problem, but one I'm not likely to do much about due to time constraints and my complete lack of doing anything with nim in quite some time. @paradox460 demonstrated some willingness to take over supplying the plugin but no idea where he's at on that. I'll gladly give any pull requests a try, but... that's probably all I have to offer, at least currently. (I should probably find someone to take over the asdf-gradle plugin, also, but it hasn't given me any grief...)

[genotrance]

This isn't a very hard fix - just need to update install to download the v0.x.0 csources instead of a sub-version. There's no need to create a separate csources for every Nim minor release.

[rfrancis]

To elaborate: thanks to @braunse for the pull request that does basically what @genotrance suggested and now the default build is working again, or at least the travis-ci build succeeds...

[ShalokShalom]

@genotrance package maintenance uses softcoded bash replacements for the according to scripts. Raising the version in these build scripts currently leads to a fail.

Simply hit that Github button to correct the links.

I suggest always triggering a version release in csources, thanks a lot.

[rfrancis]

I'm not sure what's being said here. The current plugin version builds v0.19.6 fine for me. (I goofed trying the first time, which is the only reason I reopened this. So closing it again unless someone reproduces and documents a problem.) (Also, it's basically a miracle I noticed anyone commenting. This and asdf-gradle really need new maintainers.)

[ShalokShalom]

I agree with you. Getting new developers on board and potential new maintainers is a hard task. Currently, the default way is a bash script, which is considered the worst practice of all. Security concerns and the kind of implementation in the OS distract people immediately. Package maintainers often experience very sad descriptions in the build instructions and it often puzzles me, how many developers know very less about the common hurdles in packaging. To make a specific package a breeze to build and maintain increases the chances that this packages gets upstream, in the public repositories. As already suggested in another issue: Simply touch that release button in the csources repository for each subversion, containing the exact same files as in the main version.

Case solved.

[ShalokShalom]

Another proof that nobody here in the team puts itself into the position of a potential packager: I personally see zero indication in the build instructions that the current x.0 csources is always the correct one for each according x.y version. It's just guessing game. :)

[genotrance]

The instructions on the website ask you to simply download the xz file that has everything prepackaged in one place. Downloading from github across repos is not required. The suggestion to use 0.x.0 was because the script was already using github so the change was minimal.

What is the concern with the current implementation?

[ShalokShalom]

As said, that does not sync with my distro-specific package manager. If I succeed to do so, I may loose the overview for all my packages and use effectively two different package manager solutions. Plus, since it probably adds Nim to /usr/bin or so, might it conflict sooner or later with the system libraries. Like, when somebody adds Nim to the public libraries and I install it accidentally as a dependency. That's the reason why we use package managers in the first place and the current implementation contradicts that. Secondly: There is Docker, systemd-nspawn and AppImage. Tons of services who allow us shipping one image that works on nearly each distro out of the box and isolates the files. Yes, I see Nim is unofficially supported via Docker, while I see no description who to use it via my editor of choice, as an example via VSCode.

And as said, the primary recommendation is blindly installing a bash script and that scares a significant number of people for obvious reasons.

While I am well aware that you can read this file beforehand, it is still considered a shaddy practice.

Thanks a lot :)

[genotrance]

I think there's a bunch of confusion here - this is the nim plugin for the asdf package manager. If you are a packager for some other package manager, this if the wrong forum. If not, the asdf package already works. If you have concerns with how asdf works, it is outside my expertise.

If you are a packager for some other package manager, the recommendation is to use the xz file as your starting point since it comes with everything in it. Once you build it as described in the docs, you could then build a package out of it. It doesn't install per se. Everything goes into the bin subdir.

Another suggestion is to see how other distros have included Nim. I know Ubuntu and Debian do.

Hope that helps.

[ShalokShalom]

That is all correct and does not affect what I have said.