Asdf: Make asdf more amenable to distribution packaging

[jwinnie]

Hello,

I think asdf is a really great idea and I'm trying to package it for my favorite Linux distribution, Solus. It has already been accepted for inclusion into the official repositories.

However, it seems like asdf is just a collection of scripts that are meant to be installed locally. It would be great if there were some way for distribution packagers to install it system-wide into the correct directories just like any other package. For example, the binary asdf could go in /usr/bin, the data/support files could go in /usr/share/asdf, the library/program files could go into /usr/lib/asdf, etc.

Thank you!

[Stratus3D]

Related comment: https://github.com/asdf-vm/asdf/pull/583#issuecomment-594452248

I'm open to suggestions, but without clear instruction from package/distro maintainers it's hard to know what needs to be changed to make things better for all distros.

[jthegedus]

What I would like to see from any work done on this is a separate GitHub workflow for each distro triggered from a GitHub Release so they can be automated with our existing release process and be kept up to date with our progress here.

This would avoid the GitHub issues raised because a users particular distro fell behind of the maintainer of that ecosystem's package went absent/quiet.

What are your thoughts on this @Stratus3D and @jwinnie ?

As the existing Solus asdf package maintainer @jwinnie , is migrating your packaging code to this repo be something you would be open to? (if we decide to go that route)?

[Stratus3D]

I don't think we should be responsible for packaging our software, or making distro-specific organization changes to the files. Maintaining asdf is already enough work for me, I don't want to have to also keep track of distro-specific packaging processes.

This blog post pretty well sums up my views: https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html

I do think we could greatly benefit from input from those who have created asdf packages for various operating systems (arch linux, brew on OSX, etc...). asdf started out as a script that was just installed by Git, but it has become something that is widely needed and should be easily installed by any OS package manager.

[jthegedus]

Great blog post. I largely agree with that sentiment. Though I do think centralisation of the packaging is ideal.

Perhaps another repo (maybe in the asdf-community space) is a good place to contain the packaging code. If the community is to go about packaging for various OSs, then I think a central place to manage these within the asdf ecosystem will be better.

Individuals each managing a platform they care about usually ends up in a situation where a repo gets abandoned (for whatever reason) and multiple packages for the same tool exist for a given platform (where the current working version is forced to use a new name as the prior abandoned version owns the package name for that platform). I would like to encourage a path forward where that doesn't happen. A centralised approach where the members of a team can rotate over time and have oversight is ideal IMO.

[jwinnie]

I pretty much agree with @Stratus3D on the packaging issue. It's impossible to maintain a package for every single OS out there, that would be way too much work. Creating packages is the job of the packager, not the developer.

What I was trying to say with this issue is that it's impossible to use standard packaging tools with asdf, because asdf doesn't have an install script. After looking at the code for a bit, I don't think writing an install script would be even possible without significantly changing the codebase to fit a system-wide installation model.

I would recommend the standard UNIX scheme of having a single binary called /usr/bin/asdf, the rest of the code at /usr/lib/asdf/, the data files at /usr/share/asdf/, and the configuration files at /etc/asdf.d/. But that's just because I'm most familiar with the UNIXy way to go about things.

[Stratus3D]

Individuals each managing a platform they care about usually ends up in a situation where a repo gets abandoned (for whatever reason) and multiple packages for the same tool exist for a given platform (where the current working version is forced to use a new name as the prior abandoned version owns the package name for that platform). I would like to encourage a path forward where that doesn't happen. A centralised approach where the members of a team can rotate over time and have oversight is ideal IMO.

@jthegedus I have not observed that happening with the package managers I use. yum, apt-get and brew don't seem to have that problem. It seems like the maintainers are pretty good about not accepting duplicate packages into the registries.

What I was trying to say with this issue is that it's impossible to use standard packaging tools with asdf, because asdf doesn't have an install script. After looking at the code for a bit, I don't think writing an install script would be even possible without significantly changing the codebase to fit a system-wide installation model.

@jwinnie yes, this is where the input of package maintainers would be useful. I'm open to changing things as I know the current layout isn't ideal for most OS packages.

I would recommend the standard UNIX scheme of having a single binary called /usr/bin/asdf, the rest of the code at /usr/lib/asdf/, the data files at /usr/share/asdf/, and the configuration files at /etc/asdf.d/. But that's just because I'm most familiar with the UNIXy way to go about things.

I'm open to whatever is deemed best, but we want asdf to still be easily installable with just Git like it is now. I would also like it to be possible asdf, and asdf plugins, at the system level as well as at the user level. I'm not sure how feasible that is, but right now asdf is installed per user, and I think there is a benefit in supporting that (e.g. users can install asdf in shared hosting environments without root access).

It may be useful to compile a list of currently existing asdf packages. Here are the ones I know about:

• Arch Linux: https://aur.archlinux.org/packages/asdf-vm/
• OSX via Brew: https://formulae.brew.sh/formula/asdf

[jwinnie]

The Arch Linux PKGBUILD just installs it in /opt (in case you're not familiar with Linux, /opt is basically where random miscellaneous stuff that can't be installed in the usual way goes). The Homebrew script installs it in /usr/local/Cellar/asdf.

Basically, both approaches are copying all the files of asdf into a single directory in order to "install" it system-wide. The Solus core team has made it clear that they are not willing to include packages in the repository that use this technique.