asdf

asdf copied to clipboard

Is your feature request related to a problem? Please describe

Different project use different variations of these values. I've had to write code to handle it in each plugin so it would be nice to have some premade vars to save all that work.

Describe the proposed solution

Include some globals for arch and platform with the ability to switch some on a per plugin basis

e.g

ASDF_ARCH_AMD=1

then if ARCH=x86_64 then ARCH=amd64

ASDF_PLATFORM_LCASE=1 then use lowercase PLATFORM var

Describe similar asdf features and why they are not sufficient

nothing i'm aware of

Describe other workarounds you've considered

various utils.bash files have custom code to do this.

Now that I've actually built my own set of golang binaries you might consider parsing .goreleaser.yml if it exists in the target repo as it may well contain things like this:-

    replacements:
      darwin: Darwin
      linux: Linux
      windows: Windows
      386: i386
      amd64: x86_64

infact .goreleaser.yml might do a lot of the work for us like knowing the binary name. We could if we wanted to be opinionated about it, provide some standards that we expect for .goreleaser.yml and try to get target repos on board. It will also cover Rust tools.

I'm looking into this, and it seems I can't find any information on how plugins duplicate this function natively? The ruby, elixir, and nodejs plugins don't use uname anymore. I want to add this enhancement while ensuring 100% compatibility, but it's hard if it's not in the source. Anyone have any ideas?

What is wrong with individual plugins invoking commands like uname and arch directly? In my opinion the interface between asdf core and plugins should be as small as possible. I see no reason why plugins can't whatever commands they need to get the arch/platform info for installs. Thoughts @hyperupcall @gilesw ?

A quick grep of my .asdf/plugins directory reveals that the plugins I'm using for Lua, Postgres, Java, and Python all already using uname for platform info. I don't see a problem with this.

Sort of related: https://github.com/asdf-vm/asdf/issues/1220

I invoke uname and arch in a few of my plugins (1 2).

The bigger issue for me is mapping the value of uname/arch to the name of the binary release, i.e. x86_64 -> amd64. It would be nice if there were library functions that helped with the mapping. They could handle common mappings by default, and custom mappings could be supplied (similar to @gilesw's replacements).

However this may fall more under https://github.com/asdf-vm/asdf/issues/1318

What is wrong with individual plugins invoking commands like uname and arch directly? In my opinion the interface between asdf core and plugins should be as small as possible. I see no reason why plugins can't whatever commands they need to get the arch/platform info for installs. Thoughts @hyperupcall @gilesw ?

Mostly because every plugin writer would have to write this boilerplate, and that could be avoidable. By unifying the use of uname, it would also prevent bugs in which case statements (that testing the output) are different and would lead to different architectures being used / different behavior. It would also make it significantly easier to support more architectures, because the pattern matching for more essoterric architectures and platforms would be already implemented.

If you would like, we can introduce some "standard library" mechanism and implement this in that. If done correctly, plugin writing could be more terse and straightforward. I only originally implemented it this way with environment variables because it was the only way to provide information to each plugin, but maybe that can be changed with a standard library mechanism.

I am not sure we should address this in an API provided by the core as the proposed PR to close this feature already differs in output of prior requests in this Issue. For example, the PR proposes darwin*) asdf_os='macOS', which is different to the requested Golang expected names for OSs, darwin -> Darwin. Therefore, this API is only useful to a portion of plugin authors.

Should we produce an API we know is going to be useless for a portion of users? Should we only develop APIs we know are to be used by every plugin? 🤷

Mostly because every plugin writer would have to write this boilerplate, and that could be avoidable.

My general philosophy here is that if it can be done outside of asdf in a couple lines of code, it should be. It's understandable that folks don't want to write boilerplate, but I'm also not sure enough plugin developers would bother to learn about such a feature if it were exposed. I've been perfectly happy keying off the output of uname thus far and haven't encountered any issues with it in my plugins.

By unifying the use of uname, it would also prevent bugs in which case statements (that testing the output) are different and would lead to different architectures being used / different behavior. It would also make it significantly easier to support more architectures, because the pattern matching for more essoterric architectures and platforms would be already implemented.

I might be missing something here, but plugs would still have to have case statements, the only difference would be the input would be asdf variables like asdf_arch and asdf_os. It would still be possible for there to be bugs, but the bugs could be present in either location (the case statement in core, or the cases in the plugins). Looking https://github.com/asdf-vm/asdf/pull/1402/files I really don't see any improvement over the current approach of plugins invoking uname directly.

If you would like, we can introduce some "standard library" mechanism and implement this in that. If done correctly, plugin writing could be more terse and straightforward. I only originally implemented it this way with environment variables because it was the only way to provide information to each plugin, but maybe that can be changed with a standard library mechanism.

That is good idea worth exploring. However, it's not something I will be maintaining. I think this feature request is far too broad in scope for it to be considered for asdf core right now. It's possible we may want to revisit this in the future, but given that the benefit here is debatable I think for now our efforts are better focused on other features.

Sounds good - it looks like the consensus is that this isn't something we would want to add to asdf. I suppose if a plugin maintainer really wanted to do this, they could require a prerequisite of some asdf plugin that only contains a file to source (or download a file on command). Related: #367