[Python-ideas] PEP-582 and multiple Python versions

[Calvin Spealman]

OK, I didn't know if this or -dev was more appropriate, so I opted on the
safer side in terms of annoying people.

I'll post to python-dev.

On Mon, Apr 1, 2019 at 2:27 PM Brett Cannon <brett at python.org> wrote:

> I just wanted to warn people that I don't know if any of the authors of
> PEP 582 subscribe to python-ideas and they have not brought it forward for
> discussion yet, so there's no guarantee of a response.
>
> On Mon, Apr 1, 2019 at 5:27 AM Calvin Spealman <cspealma at redhat.com>
> wrote:
>
>> While the PEP does show the version number as part of the path to the
>> actual packages, implying support for multiple versions, this doesn't seem
>> to be spelled out in the actual text. Presumably __pypackages__/3.8/ might
>> sit beside __pypackages__/3.9/, etc. to keep future versions capable of
>> installing packages for each version, the way virtualenv today is bound to
>> one version of Python.
>>
>> I'd like to raise a potential edge case that might be a problem, and
>> likely an increasingly common one: users with multiple installations of the
>> *same* version of Python. This is actually a common setup for Windows users
>> who use WSL, Microsoft's Linux-on-Windows solution, as you could have both
>> the Windows and Linux builds of a given Python version installed on the
>> same machine. The currently implied support for multiple versions would not
>> be able to separate these and could create problems if users pip install a
>> Windows binary package through Powershell and then try to run a script in
>> Bash from the same directory, causing the Linux version of Python to try to
>> use Windows python packages.
>>
>> I'm not actually sure what the solution here is. Mostly I wanted to raise
>> the concern, because I'm very keen on WSL being a great entry path for new
>> developers and I want to make that a better experience, not a more
>> confusing one. Maybe that version number could include some other unique
>> identify, maybe based on Python's own executable. A hash maybe? I don't
>> know if anything like that already exists to uniquely identify a Python
>> build or installation.
>>
>> --
>>
>> CALVIN SPEALMAN
>>
>> SENIOR QUALITY ENGINEER
>>
>> cspealma at redhat.com  M: +1.336.210.5107
>> <https://red.ht/sig>
>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspealma at redhat.com  M: +1.336.210.5107
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190402/3a4c9c2c/attachment.html>