pkgxdev
Creating environments for python packages?
Can I tea +pip.pypa.io pip install Y to a different environment than tea +pip.pypa.io pip install X? It looks like right now they're all installed in ~/.tea/python.org/v3.11.0/lib/python3.11/site-packages. It would be great if I can separate them.
I believe you can change install location with either a command line flag (to pip) or an environment variable it responds to. Possibly PYTHONPATH or --target (from memory and a quick Google).
Is there no plan to have Tea manage other product environments? It's fine if that's what you guys want. Homebrew had formulas for a lot of python packages (even though the Python folks discouraged it). I am trying to remove all of my Homebrew installs and replace them with Tea. Python packages are what I am working on now.
I think you guys are doing something like this with pip. This tea +python.org pip installs python.org and pip.pypa.io.
We definitely are targeting seamless management of language environments. We do have the package managers for the various languages we have available, and they depend on their languages, so tea +pip.pypa.io pip install foo or tea -X pip install foo or tea +pip.pypa.io for a REPL should all work today.
Python venvs are an interesting edge-case, that most languages (I've looked at) don't seem to use. Those require some complicated logic, such as mesonbuild.com/package.yml that we'll definitely want to handle in a reasonably transparent fashion. So, we are interested in input from Python users in ways to handle sandboxed python sensibly.
Ok. I think I've figured this out.
If I install something with tea +python.org pip install X, it will go in ~/.tea/python.org/v3.11.0/bin and its dependencies go in ~/.tea/python.org/v3.11.0/lib/python3.11/site-packages. I don't think there's anything you guys can really do about this (and I'm not sure you'd want to). The same goes for anything installed with pipenv, except it installs to ~/.local/share/virtualenvs.
Note, pipenv makes python virtual environments extremely easy, and it's part of the official python project, but it's not installed by default. Also, pipenv also modifies the 1st line of every script and it hardcodes the path to python, e.g. #!/Users/u0076374/.local/share/virtualenvs/jctl-tmpstr/bin/python. That path is a symlink, which points to the version of python that is used to install pipenv (I think) or the version specified to pipenv, like this, tea +python.org pipenv --python /usr/local/bin/python3 install X.
However, what I really want is what you are doing with pip.pypa.io. And to get that, I just need to create a package for my project. But I just looked at your mesonbuild package.yml file and yeah, that's complex. I will start looking into this. A lot of the tools I install with brew are python, so I definitely want to figure this out.
Right, because pipenv hardcodes paths, I had to fudge some stuff to make it relocatable, including updating the virtualenv on the fly at invocation time. It is likely that this counters the intention of python's virtual environment in favor of our own.
My understanding from working with pip is that the packages installed are closely tied to the python version that installed them, so, it seemed natural that their preference was to be installed with python itself. This isn't great sandboxing however, but python's module resolution was being quite tricky.
Which is a long-winded way of saying that we need smart python lovers, like yourself, @magnusviri , to help us figure out how best to hook all this together. We really appreciate all the work you've already done to help us organize and sort out the parts of tea that are attractive to you.
Hahahaha, I only just started to figure out python's environment stuff, and only because I was briefly involved with stable diffusion and was trying to make it easy to install on macOS. My usual way of dealing with python problems is finding every version of it and rm -r'ing them and starting over. In fact, I kind of still employ this technique. I can try to rope in some python devs who know way more than me, but I think it might be best to wait until more documentation and basic features are ironed out.
I'm closing this because I think https://github.com/teaxyz/pantry.core/pull/54 is basically the answer.