[ActorNightly]

No and no. I don't know how you even get to this level of "making it harder for yourself".

Say you want to use a specific version of python that is not available on Ubuntu.

1. Install build dependencies https://devguide.python.org/getting-started/setup-building/#...

2. Download whichever Python source version you want, https://www.python.org/downloads/source/. Extract it with tar

3. run ./configure --enable-optimizations --with-lto

4. run make -s -j [num cores]

5. sudo make altinstall

This will install that specific version without overwriting default system python.

You can then bash alias pip to python3.xx -m pip to make sure it runs the correct one.

All the libraries and any pip install executable will be installed locally to ~/.local folder under the specific python version.

Alternatively, if you work with other tools like node and want to manage different versions, you can use asdf, as it gives you per folder version selection.

virtual environments are really only useful for production code, where you want to test with specific versions and lock those down.

[dragonwriter]

Virtual environments are useful for isolating dependencies for different projects, not just isolating the interpreter.

(I mean, except on Windows, your venvs default to symlinking the interpreter and other shared bits, so you aren't really isolating the interpreter at all, just the dependencies.)

[ElectricalUnion]

AFAIK, it's the same even on POSIX, when you create a venv, "./bin/python" are symlinks and the pyvenv.cfg has a hardcoded absolute path of the current python interpreter the venv module was using at the time of creation. It really doesn't isolate the interpreter.

(also one of the reasons why, if you're invoking venv manually, you absolutely need to invoke it from the correct python as a module (`python3.13 -m venv`) to make sure you're actually picking the "correct python" for the venv)

[dragonwriter]

I meant that the symlink behavior is default except on Windows (though it may just be on POSIX platforms and I think of it as “except Windows” because I don't personally encounter Python on non-Windows non-POSIX platforms.)

[MintPaw]

> making it harder for yourself

Looking at just the first link, looks way more complicated than venv. And I'm a C++ developer, imagine someone who less experienced, or even who just isn't familiar with C toolchains.

[sevensor]

It’s really not hard; the person you’re replying to put a lot of details in. I’ve lost track of how many times I’ve built a Python interpreter. Virtual envs used to work badly with some tools and dependencies, so I had to do it a lot. It’s gotten better and now I only compile Python to get a version that’s not provided by my Linux distribution.

[ActorNightly]

The first link is a sudo apt install command that you copy paste into terminal. in what world is that more complicated than venv?

Here it is for clarity

sudo apt-get install build-essential gdb lcov pkg-config \ libbz2-dev libffi-dev libgdbm-dev libgdbm-compat-dev liblzma-dev \ libncurses5-dev libreadline6-dev libsqlite3-dev libssl-dev \ lzma lzma-dev tk-dev uuid-dev zlib1g-dev libmpdec-dev libzstd-dev

[MintPaw]

Even what you just pasted is wrong. And it would give a confusing error if you used it. Try "sudo apt install vim \ make" to see.

It's the kinda thing an experienced engineer wouldn't have that much trouble with, but you should be able to recognize how much experiential knowledge is required to compile a complex C code base and what kinda dumb stuff can go wrong.

You probably don't need to do much of the stuff on that page to build, but "What is dnf?", "Is the pre-commit hook important?", "Do I need cpython?", "What's an ABI dump?" are questions many people will the wrestling with while reading.

[zahlman]

> The first link is a sudo apt install command that you copy paste into terminal. in what world is that more complicated than venv?

venvs also aren't complicated.

I have built Python from source before, many times. I do it to test Python version compatibility for my code, investigate performance characteristics etc.

Re-building the same version of Python, simply in order to support a separate project using the same version with different dependencies, is a huge waste of time and disk space (hundreds of MB per installation, plus the mostly-shared dev dependencies). Just make the virtual environment. They are not hard to understand. People who want a tool to do that understanding for them are welcome to waste a smaller amount of disk space (~35MB) for uv. A full installation of pip weighs 10-15MB and may take a few seconds; you normally only need one copy of it, but it does take some work to avoid making extra copies.

[icedchai]

Personal preference, but I prefer to use 'mise' instead of 'asdf' these days: https://mise.jdx.dev/