On Jul 3, 2019, at 03:54, Stefan Droege <stefan@sdroege.de> wrote:
Currently, when creating a virtualenv with the PEP-405 `venv` module, the python-config executable will not be copied/symlinked to the virtualenv.
That means for projects that link against the python interpreter, *and* which are built in a venv virtual environment, some custom "magic" has to be done to find the correct `python-config` executable in order to get the full name of libpython.
But with your proposed change, wouldn’t this mean that building a project for system-wide installation would be broken by having a venv active? In fact, looking at the virtualenv issue, it looks like that’s what people are actually asking for: they’re trying to use a package manager to, e.g., “brew install opencv”, and they want it to ignore the package-managed Python and instead build against the active virtualenv. That seems like a recipe for disaster (except for people who only have a single user and a single env that they keep activated 100% of the time, in which case, do they even need virtual environments?). Maybe this isn’t really an issue. After all, export LD_LOAD_LIBRARY has the same issue. But venv is more novice-friendly than that, and people might be misled and not even realize it, because they’re not doing anything “advanced”, just following standard practices for Python development. Anyway, your own use case seems better. Presumably you’re building cocotb locally, to be used within the specific project that uses the currently activated Python environment. And I’m sure you’re not unique. But is there a design that would allow that to work for you, without silently breaking things for people mistakenly trying to run global installs against a venv? Maybe a way to explicitly ask for python-config as part of the venv creation, or a command to switch it on the fly, or even just a much simpler (and clearly documented) way to do the “magic” so you don’t have to waste a weekend trying to hack it into shape? Also, it looks like the way virtualenv solved this was not to copy the script from the live Python, but to embed a custom script in virtualenv, which was forked from the latest (at the time) Python and then patched to also work with 2.x. Your proposed solution seems a lot better, but did you check whether there was a reason they did it that way?