bug: allow system version to come before asdf versions

[glyph]

Describe the Bug

I install the current Python from python.org but use asdf for managing older versions for integration testing. If I do asdf global python system 3.8.12 3.7.12 3.6.15 and then python3.6, it says No python3.6 executable found for python system. If I put asdf's versions first it has no trouble.

Steps to Reproduce

Install asdf, install some pythons, asdf global python system <something that isn't system>, use <something that isn't system>'s version, see error above.

Expected Behaviour

I'd want to have python3.6 python3.7 python3.8 et. al. on my path without obscuring system versions.

Actual Behaviour

Error message as above.

Environment

OS:
Darwin arabella.local 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000 arm64

SHELL:
zsh 5.8 (x86_64-apple-darwin21.0)

ASDF VERSION:
v0.9.0

ASDF ENVIRONMENT VARIABLES:
ASDF_DIR=/opt/homebrew/opt/asdf/libexec

ASDF INSTALLED PLUGINS:
python                       https://github.com/danhper/asdf-python.git master 57a4d72

asdf plugins affected (if relevant)

python

[rud]

A proposal: I think your life would be much easier if you used asdf to install all the python versions you want to access. Consistency is much simpler, I find.

[andrewcrook]

My system defaults where Python 2.7 (now removed from macOS) and Python 3 from homebrew which overrides the system Python 3. With homebrew Python3 is a dependency of many other packages and they control the version(s). So I set global as system , to insure things work, then custom locals for projects and custom environments i.e .tool-versions. I would like asdf show the versions of the system defaults. Eg

10.5.2 (system)

[mindovermiles262]

Change the way asdf is loaded in your PATH so that ASDF is loaded before any of your system shims

[polarathene]

I'd want to have python3.6 python3.7 python3.8 et. al. on my path without obscuring system versions.

What is the point of having all of these as global, vs using .tool-versions to set a local version where appropriate? Or if running tests as you mention, adjusting the ENV ASDF_PYTHON_VERSION instead of the versioned executable to run?

The python plugin doesn't seem to advise using system like this, and their README example demonstrates the intent mainly for Python 2.x + 3.x under the same plugin.

This issue also exists at asdf-python.

---

With homebrew Python3 is a dependency of many other packages and they control the version(s). So I set global as system , to insure things work, then custom locals for projects and custom environments i.e .tool-versions.

Does macOS not install homebrew packages under a different (system) user? You could perhaps instead use an ENV with the command (or hide that away with an alias?) to use the system version?

Alternative, just use local or shell versions, or change global between system and whatever you prefer when you need it?

For example, asdf global python system. Then when you need to work with a different version temporarily asdf shell python 3.6, or do the opposite for calling homebrew (asdf shell python system; homebrew).

[SergiyKolesnikov]

Pyenv supports the behavior described by @glyph:

root@62c8cadea516:~# pyenv global system 3.10.0 3.9.0
root@62c8cadea516:~# pyenv versions
* system (set by /root/.pyenv/version)
* 3.9.0 (set by /root/.pyenv/version)
* 3.10.0 (set by /root/.pyenv/version)
root@62c8cadea516:~# python3
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@62c8cadea516:~# python3.9
Python 3.9.0 (default, Sep 19 2023, 15:07:31) 
[GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

root@62c8cadea516:~# python3.10
Python 3.10.0 (default, Sep 19 2023, 15:08:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

I'd want to have python3.6 python3.7 python3.8 et. al. on my path without obscuring system versions.

What is the point of having all of these as global, vs using .tool-versions to set a local version where appropriate?

@polarathene For me the use-case is to preserver the system Python version as default for programs that rely on it (for example, those installed with the system package manager) and at the same time allow "smart" tools that can use versioned Python binaries do their magic. For example, poetry knows which version of Python is needed for a given project and can look for the corresponding versioned Python binary, so there is no need in .tool-versions.

[andrewcrook]

I am not for this change. It's not a bug its not how asdf is meant to work and will totally change its usage. just use global, local .tool-versions and per project using .tool-versions.

An alternative? I would suggest writing script(s) or alias to create new shells and useasdf shell( or ASDF_${LANG}_VERSION) to change the python version in each and have these scripts on path in front of asdf. and name these python3.10 python3 etc Something like ..

alias python3.10="bash --rcfile <(echo '. ~/.bashrc; asdf shell python 3.10.12')”

note, .bashrc must contain the asdf setup. You could use scripts rather than aliases I expect you could make /usr/bin/env support them. So it will support hash bangs.

Personally I use direnv and asdf-direnv to have different versions and virtual environments on a per project bases and it’s automated. I use Global for system default, local for user and .tool-versions and direnv per project.