221–230 of 341 posts
Earlier quoted context omitted.
You only need pip and virtualenvwrapper requirements.txt is a text file, not a separate tool... if you want your program to work exactly as intended in the future, there are tools like py2exe and py2app for that.
Don't need any wrappers either. venv has been built into python for ages.
Earlier quoted context omitted.
These builds are an alternative: https://github.com/indygreg/python-build-standalone Those are what Rye and hatch use. Drawbacks: late availability of patch versions, various quirks from how they are built (missing readline, missing some build info that self-compiled C python modules might need.)
I think PEP711 ( https://peps.python.org/pep-0711/ ) is (eventually) a better alternative, because it builds on top of the proven manylinux approach to binary compatibility.
Earlier quoted context omitted.
> Every solution that I know of on Linux requires you to build Python on the machine Unless you need a Python that's not supported by your Linux distribution, you can just use what's available. On macOS, MacPorts provides compiled versions for 3.2 all the way to 3.13, as well as 2.6 and 2.7. Right now, I have 3.8, 3.9, 3.10, 3.11, 3.12, and a 3.13 development build. The fact it's not Linux (or x86) might cause some f…
If you’re lucky enough to be on a Linux system that uses apt some thankless soul maintains a repo called deadsnakes with all these binaries. Fabulous if you’re using any somewhat old version of Python in CI for instance. Yum based systems are SOL as far as I can tell. Build and host your own binary for that. Apk doesn’t have this either IIRC
Drop by and send thanks cause he really needs them.
Earlier quoted context omitted.
> but a python venv does make sure you're using the same runtime. It does not. > There are symlinks in the environments bin directory to the specific runtime. Precisely. They symlink to a path . Which means that if you have a certain version of Python at one location (let’s say /usr/bin/python3) and later update that (let’s say by upgrading macOS and the Xcode developer tools), the same virtual environment will point…
The binary installs aren't that generic in the machines I've used (mac and debian based, so covers a fair bit). It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Upgrading just changes the symlink, which wouldn't affect the venv, which isn't using python3, it's using python3.11. I didn't introduce anything, I explained how the links…
Not for the example I gave. If you’re seeing Python 3.11, you’re definitely not using the /usr/bin/python3 on macOS with is made available by the Xcode CLI tools. That’s at 3.9.6 even on Sonoma.
> as someone else also points out, you don't even have to use the symlinked versions, you can use --copies
Which, again, doesn’t work for the stated case.
I used to use this a lot when working on a Windows machine. Worked pretty well. But nowadays Nix solves the same problem in a fully general way, for all software rather than a single language. You can have whatever versions of whatever you want, side by side, without interfering with each other.
What is your solution here? Are you using a project-specific flake? Do you still install packages with pip?
I have to warn again users that think they have found the silver bullet that pyenv comes with a big caveat: it compiles python on your machine. The number of possible modes of failure in this situation is huge. See also: "Why not tell people to "simply" use pyenv, poetry or anaconda" https://www.bitecode.dev/p/why-not-tell-people-to-simply-use I'm not saying pyenv is not a useful tool, but it is not a tool for beginn…
Earlier quoted context omitted.
That happens way more often than people want to admit, and I think it's not genuine to present the tool that way. E.G, I'm on Ubuntu 20.04 on an Dell XPS, a fairly standard machine, I'll get: pyenv install 3.9 -v /tmp/python-build.20240325124651.73089 ~ Downloading Python-3.9.19.tar.xz... -> https://www.python.org/ftp/python/3.9.19/Python-3.9.19.tar.xz ... LD_LIBRARY_PATH=/tmp/python-build.20240325124651.73089/Python…
Actually, I'm pretty sure that binaries for Python 3.9 aren't available on Ubuntu 20.04 without adding an apt repository to get them from, so your statement that you "can apt install it" isn't entirely correct in this case - by default, binaries aren't available, and therefore pyenv has to compile Python 3.9.
Earlier quoted context omitted.
These builds are an alternative: https://github.com/indygreg/python-build-standalone Those are what Rye and hatch use. Drawbacks: late availability of patch versions, various quirks from how they are built (missing readline, missing some build info that self-compiled C python modules might need.)
I think PEP711 ( https://peps.python.org/pep-0711/ ) is (eventually) a better alternative, because it builds on top of the proven manylinux approach to binary compatibility.
Earlier quoted context omitted.
None. The software container image is the best bet but you need to keep the image and not only the building scripts.
This is not true. Nix actually solves the problem. If you package with Nix, you'll get the exact same version of Python with the exact same version of dependencies, including the exact same version of system libraries. Your build will work in a year just as it does today. You don't even need to keep any binary artifacts. Of course this doesn't come free: packaging with Nix may involve nontrivial effort for some proje…