feature: make install easier for unixers with asdf

[airtonix]

This PR adds a tool version manifest for asdf and a quick bootstrap bash file that will setup asdf on your system (linux and mac users only)

For Linux, don't recommend using system python, it just leads to destroyed desktop environments as people inevitably try to install conflicting packages that can't be put in an venv.

asdf will install python the same way regardless of linux/mac os version/family (so only one setup instructions required)

[comfyanonymous]

I'm sorry but I'm not familiar with asdf. I have always used system python on linux (with pip packages installed as user and the occasional venv).

Is there any problem with doing it that way?

[airtonix]

@comfyanonymous Yeah there is, but it's not always obvious at first.

Most linux desktop operating systems rely on python for their desktop environments, much like how Macos relies on Ruby for some OS operations.

Here's a range of problems I've experienced over the last ten'ish years:

before you discover virtual env

• you want to install latest pillow, but it needs you to install a more recent version of another python package. so you update that package. 💀 ubuntu relied on that, and so it's now broken because: reasons.

So you learn about virtualenvs:

the obvious problems go away.

But now you're working on projects that need to work for many years. You think you're a smart cookie by pinning your packages, but you assumed that these particular versions of those apackages would work with any version of python 3.x.

imagine your surprise and / or frustration when:

• you come back 6 mths later, the project mysteriously won't pip install because of some api drift between the package and python.
• you've been deploying a project for the last 6 mths with no problems, but suddenly today the build fails, or even worse: it doesnt fail, but at runtime users are reporting exceptions. after many hours wasted and quite a few misleading discoveries you realise that your build and runtime environment has magically and annoyingly upgraded the version of python your deployment uses.

Another annoying problem when you only rely on dnf install python-some-official-version :

• you can't experiement with packages that need a version you can't dnf install
• you might be tempted to return to the scenario ☝🏻 , 👏🏻 now your wsl2/ubuntu-vm/fedora-vm is broken and well: how to undo that? sometimes it's basically easier to reinstall the OS

In most projects, people use Docker to solve this problem. Which is fine for systems that horizontally scale the workload. And when used properly Docker basically eliminates your dependancies as issues once you QA it properly.... they're set in stone.

ASDF lets you pin the versions of all kinds of tools/engines without having to deal with the overhead of docker (or even worse: virtual machines):

There is no more:

• forgetting what version of python/ruby/java/jq/golang/bat/ripgrep/fzf you needed to make the project work properly: it's in the .tool-versions and you just run asdf install
• no more wondering how you install said tool: asdf install
• if you're like most curious software engineers, then you more than likely have eleventy billion folders in you ~/Projects over the last couple of years... each probably broken now because you forgot what version of X, Y, z it needed.

final note: Look at how the more bullet proof docker images setup nodejs or ; they rarely do it by installing the language engine from the os repos.

[BuildBackBuehler]

After just dealing with this nightmare again and stumbling upon this thread as I try to figure out how to resolve my issues, I'd just like to throw my hat into this discussion. I think this is especially relevant for Mac users because of Homebrew's unreliable Python build. I get errors out the wazoo even when I've installed pipenv and use the venv. as there, as my error logs call it, a "leak" wherein custom nodes are trying to import something like "shutil.py." When it is executed, (I suppose Cpython doesn't have shutil.py?) it is relayed back to my Homebrew Python build and causes

[!] File "/opt/homebrew/Cellar/python@3.11/3.11.6_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/shutil.py", line 744, in rmtree [!] onerror(os.path.islink, path, sys.exc_info()) [!] File "/opt/homebrew/Cellar/python@3.11/3.11.6_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/shutil.py", line 742, in rmtree [!] raise OSError("Cannot call rmtree on a symbolic link") [!] OSError: Cannot call rmtree on a symbolic link

However, I'd suggest what is essentially "Rust ASDF" or "ASDF 2.0", rtx. It not only acts as a package-man-to-rule-them-all but it is extremely speedy and has a phenomenal error log that is actually readable and thus actionable thanks to Rust.

https://github.com/jdx/rtx/

More error log snippet fun

errorlogz.txt