I wonder if you could help me settle a small dispute with some colleagues. In short: they are convinced that it is for some reason “unsupported”, if not outright verboten, to install non-Python programs and libraries into a virtual environment created with venv.
My opinion on this is of course you can do this: Beyond the magic bits supported by the Python interpreter and site.py (e.g. for reading pyvenv.cfg) it is no different from any other alternate install prefix. Installing, say, an autoconf package into a venv is little more than a matter of ./configure --prefix=$VIRTUAL_ENV && make && make install. Plus the usual caveats, e.g. of setting the correct LDFLAGS to linking things that are not in the default library search path.
I have been doing this successfully, when necessary, for over a decade in virtual environments created with both venv and virtualenv.
AFAICT the only source of their opinion on this is that none of the official docs either on packaging.python.org or docs.python.org explicitly mention this use case; I just assumed it’s not mentioned because it either goes without saying, or is safer to remain agnostic about.
IMO both camps have their point. This is definitely “unsupported” in the sense that the developers don’t really have this scenario in mind—which is also why it is mentioned nowhere—and you’re more or less on your own if you hit any problems that don’t happen to align with the intended use cases.
OTOH it is also very unlikely you’d hit any significant roadblocks, since the virtual environments, as you have observed, are just like any normal install prefixes. The design is intentional because that structure is built into the implementation, and is essential for virtual environments to work. Come to think of it, extension modules are also just C dylibs following a specific convention, and when you install one from source the venv is basically tricking Python into doing the same linker flag configuration under the hood as you do. So in that sense what you have in mind is also definitely “supported” since it is the backbone to the idea of virtual environments itself.
Come to think of it, extension modules are also just C dylibs following a specific convention, and when you install one from source the venv is basically tricking Python into doing the same linker flag configuration under the hood as you do.
Exactly. The main trick is just that if you want to link, say, against a C library that’s installed in the virtualenv it’s necessary to pass the correct linker flags, such as rpath. But this is true for any non-default install prefix.