PEP-517 - definition of isolated build environments breaks sysconfig contract

In my experience :smiley: Some people do have a use case of liking to use it when they don’t have admin rights on the machine; however almost without a fail after a few months they run into the problem of the user site package and the global site package start to conflict. IMHO they would have been better off creating a virtual environment in their home directory and installing their stuff to avoid the headache and confusion (or just use pipx). IMHO --user is broken by design and source of a lot of confusion for new users.

By default, pip falls back to user installs if the system site-packages is read-only, and Debian has patched their pip to make --user the default. So I don’t see user installs going away any time soon.

I know, I’m already paying the price of that, as I already got a few bug reports on virtualenv where users installed differing versions of virtualenv on the OS level and on the user site package level. And then they are surprised why they’re getting runtime errors of cannot import module x (we removed x in a later version, so if you mix and match different versions of python packages in the same interpreter you’ll have a bad time). This wasn’t the best decision on our side IMHO and it just generates confusion for new users and needless time churn on maintainers of the tools trying to explain this to the users… I personally keep recommending to people to avoid --user as the plague. It might work today, but eventually you’ll have a long afternoon of debugging and being confused.

It looks like discussion has focused on the sysconfig part of this, but the other part - specifying that the scripts from build dependencies should be first on PATH - seems quite reasonable. I would imagine that any implementations already prepend the scripts directory, so this would probably be uncontroversial.

Like others have said, I’ve always treated {sys.executable} -m module as the canonical way to run Python code in a subprocess, ensuring it runs in the same environment. I’d request basically any Python tool with a CLI to support -m - it’s usually about 3 lines of extra code. But if they won’t for any reason, workarounds using sys.executable in other ways are possible (e.g. {sys.executable} -c "from foo import main; main()").

FWIW, I use --user installation quite a bit (partly due to laziness). I also let beginner programmers do likewise - I’m well aware of all the benefits of virtualenvs, but they’re a big extra thing for people to get their head around at a point when they’re trying to take in a whole load of other new concepts and tools.

1 Like

If you’re doing it for tools you can always just use pipx, everyone will have a better time :smiley: