Re: [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  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 
> 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
>>
>> cspea...@redhat.com  M: +1.336.210.5107
>> 
>> TRIED. TESTED. TRUSTED. 
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107

TRIED. TESTED. TRUSTED. 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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  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
>
> cspea...@redhat.com  M: +1.336.210.5107
> 
> TRIED. TESTED. TRUSTED. 
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Calvin Spealman]

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

cspea...@redhat.com  M: +1.336.210.5107

TRIED. TESTED. TRUSTED. 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/