[Python-Dev] Deprecate PEP 370 Per user site-packages directory?
171 views
Skip to first unread message
Christian Heimes
Jan 13, 2018, 12:08:07 PM1/13/18
to pytho...@python.org
Hi,
PEP 370 [1] was my first PEP that got accepted. I created it exactly one
decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
virtual environment support in Python. Ian Bicking had just started to
create the virtualenv project a couple of months earlier.
Fast forward 10 years...
Nowadays Python has venv in the standard library. The user-specific
site-packages directory is no longer that useful. I would even say it's
causing more trouble than it's worth. For example it's common for system
script to use "#!/usr/bin/python3" shebang without -s or -I option.
I propose to deprecate the feature and remove it in Python 4.0.
Regards,
Christian
[1] https://www.python.org/dev/peps/pep-0370/
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
PEP 370 [1] was my first PEP that got accepted. I created it exactly one
decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
virtual environment support in Python. Ian Bicking had just started to
create the virtualenv project a couple of months earlier.
Fast forward 10 years...
Nowadays Python has venv in the standard library. The user-specific
site-packages directory is no longer that useful. I would even say it's
causing more trouble than it's worth. For example it's common for system
script to use "#!/usr/bin/python3" shebang without -s or -I option.
I propose to deprecate the feature and remove it in Python 4.0.
Regards,
Christian
[1] https://www.python.org/dev/peps/pep-0370/
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
Random832
Jan 13, 2018, 1:06:30 PM1/13/18
to pytho...@python.org
On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> I propose to deprecate the feature and remove it in Python 4.0.
Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> I propose to deprecate the feature and remove it in Python 4.0.
Christian Heimes
Jan 13, 2018, 1:20:39 PM1/13/18
to pytho...@python.org
On 2018-01-13 19:04, Random832 wrote:
> On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
>> Hi,
>>
>> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
>> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
>> virtual environment support in Python. Ian Bicking had just started to
>> create the virtualenv project a couple of months earlier.
>>
>> Fast forward 10 years...
>>
>> Nowadays Python has venv in the standard library. The user-specific
>> site-packages directory is no longer that useful. I would even say it's
>> causing more trouble than it's worth. For example it's common for system
>> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>>
>> I propose to deprecate the feature and remove it in Python 4.0.
>
> Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
I see two option:
> On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
>> Hi,
>>
>> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
>> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
>> virtual environment support in Python. Ian Bicking had just started to
>> create the virtualenv project a couple of months earlier.
>>
>> Fast forward 10 years...
>>
>> Nowadays Python has venv in the standard library. The user-specific
>> site-packages directory is no longer that useful. I would even say it's
>> causing more trouble than it's worth. For example it's common for system
>> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>>
>> I propose to deprecate the feature and remove it in Python 4.0.
>
> Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
1) "pip install --user" is no longer supported. You have to learn how to
use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
install package".
2) "pip install --user" automatically creates or uses a custom virtual
(~/.pip/virtualenv-$VERSION/) and links entry points to ~/.local/bin.
Christian
Antoine Pitrou
Jan 13, 2018, 1:59:30 PM1/13/18
to pytho...@python.org
On Sat, 13 Jan 2018 19:18:41 +0100
Christian Heimes <chri...@python.org> wrote:
> On 2018-01-13 19:04, Random832 wrote:
> > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> >> virtual environment support in Python. Ian Bicking had just started to
> >> create the virtualenv project a couple of months earlier.
> >>
> >> Fast forward 10 years...
> >>
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful. I would even say it's
> >> causing more trouble than it's worth. For example it's common for system
> >> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> >>
> >> I propose to deprecate the feature and remove it in Python 4.0.
> >
> > Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
>
> I see two option:
>
> 1) "pip install --user" is no longer supported. You have to learn how to
> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> install package".
> 2) "pip install --user" automatically creates or uses a custom virtual
> (~/.pip/virtualenv-$VERSION/) and links entry points to ~/.local/bin.
Option 2 doesn't work, since the installed package then isn't known to
Christian Heimes <chri...@python.org> wrote:
> On 2018-01-13 19:04, Random832 wrote:
> > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> >> virtual environment support in Python. Ian Bicking had just started to
> >> create the virtualenv project a couple of months earlier.
> >>
> >> Fast forward 10 years...
> >>
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful. I would even say it's
> >> causing more trouble than it's worth. For example it's common for system
> >> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> >>
> >> I propose to deprecate the feature and remove it in Python 4.0.
> >
> > Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
>
> I see two option:
>
> 1) "pip install --user" is no longer supported. You have to learn how to
> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> install package".
> 2) "pip install --user" automatically creates or uses a custom virtual
> (~/.pip/virtualenv-$VERSION/) and links entry points to ~/.local/bin.
the system Python.
I'm not sure user site-packages adds a lot of complexity to Python, so
I don't think it's worth breaking some people's usage.
Regards
Antoine.
Miro Hrončok
Jan 13, 2018, 2:14:16 PM1/13/18
to pytho...@python.org
On 13.1.2018 18:06, Christian Heimes wrote:
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
While I consider venvs easy and cool, this just moves the barrier for
the users a little bit higher. We (Fedora Python SIG) are fighting users
that run `sudo pip install` all the time (because the Interwebz are full
of such instructions). The users might be willing to listen to "please,
don't use pip with sudo, use --user instead". However, if you tell them
"learn how to use a venv", they'll just stick with sudo.
> I propose to deprecate the feature and remove it in Python 4.0.
We would very much like to see --user the default rather than having it
removed.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Paul Sokolovsky
Jan 13, 2018, 2:35:53 PM1/13/18
to Christian Heimes, pytho...@python.org
Hello,
[]
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful. I would even say
> >> it's causing more trouble than it's worth. For example it's common
> >> for system script to use "#!/usr/bin/python3" shebang without -s
> >> or -I option.
> >>
> >> I propose to deprecate the feature and remove it in Python 4.0.
> >
> > Where would pip install --user put packages, and how would one run
> > scripts that require those packages? Right now these things Just
> > Work; I've never had to learn how to use virtual environments.
>
> I see two option:
>
> 1) "pip install --user" is no longer supported. You have to learn how
> to use virtual envs. It's really easy: "python3 -m venv path;
> path/bin/pip install package".
Easy for whom? C, Ruby, JavaScript users, random grandmas and
grandpas? Please don't make innocent hate Python, and don't make
developers who chose Python to develop software hate it for
impossibility to provide decent user support for their software.
--
Best regards,
Paul mailto:pmi...@gmail.com
[]
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful. I would even say
> >> it's causing more trouble than it's worth. For example it's common
> >> for system script to use "#!/usr/bin/python3" shebang without -s
> >> or -I option.
> >>
> >> I propose to deprecate the feature and remove it in Python 4.0.
> >
> > Where would pip install --user put packages, and how would one run
> > scripts that require those packages? Right now these things Just
> > Work; I've never had to learn how to use virtual environments.
>
> I see two option:
>
> 1) "pip install --user" is no longer supported. You have to learn how
> to use virtual envs. It's really easy: "python3 -m venv path;
> path/bin/pip install package".
grandpas? Please don't make innocent hate Python, and don't make
developers who chose Python to develop software hate it for
impossibility to provide decent user support for their software.
--
Best regards,
Paul mailto:pmi...@gmail.com
Oleg Broytman
Jan 13, 2018, 2:42:03 PM1/13/18
to pytho...@python.org
Hi!
On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes <chri...@python.org> wrote:
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful.
Can I disagree?
> I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
System scripts are run under user root which seldom has user-specific
site-packages so why worry?
> I propose to deprecate the feature and remove it in Python 4.0.
>
> Regards,
> Christian
>
> [1] https://www.python.org/dev/peps/pep-0370/
Oleg.
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes <chri...@python.org> wrote:
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful.
> I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
site-packages so why worry?
> I propose to deprecate the feature and remove it in Python 4.0.
>
> Regards,
> Christian
>
> [1] https://www.python.org/dev/peps/pep-0370/
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
Oleg Broytman
Jan 13, 2018, 2:59:29 PM1/13/18
to pytho...@python.org
On Sat, Jan 13, 2018 at 07:18:41PM +0100, Christian Heimes <chri...@python.org> wrote:
> On 2018-01-13 19:04, Random832 wrote:
> > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> >> virtual environment support in Python. Ian Bicking had just started to
> >> create the virtualenv project a couple of months earlier.
> >>
> >> Fast forward 10 years...
> >>
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful. I would even say it's
> >> causing more trouble than it's worth. For example it's common for system
> >> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> >>
> >> I propose to deprecate the feature and remove it in Python 4.0.
> >
> > Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
>
> I see two option:
>
> 1) "pip install --user" is no longer supported. You have to learn how to
> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> install package".
I've learned virtual envs and use them every day. I also use
> On 2018-01-13 19:04, Random832 wrote:
> > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> >> virtual environment support in Python. Ian Bicking had just started to
> >> create the virtualenv project a couple of months earlier.
> >>
> >> Fast forward 10 years...
> >>
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful. I would even say it's
> >> causing more trouble than it's worth. For example it's common for system
> >> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> >>
> >> I propose to deprecate the feature and remove it in Python 4.0.
> >
> > Where would pip install --user put packages, and how would one run scripts that require those packages? Right now these things Just Work; I've never had to learn how to use virtual environments.
>
> I see two option:
>
> 1) "pip install --user" is no longer supported. You have to learn how to
> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> install package".
``pip install --user``. Different use cases. Virtual envs are for
development, ``pip install --user`` for deployment.
> Christian
Oleg.
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
Christian Heimes
Jan 13, 2018, 3:02:21 PM1/13/18
to pytho...@python.org
On 2018-01-13 20:08, Oleg Broytman wrote:
> Hi!
>
> On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes <chri...@python.org> wrote:
>> Hi,
>>
>> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
>> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
>> virtual environment support in Python. Ian Bicking had just started to
>> create the virtualenv project a couple of months earlier.
>>
>> Fast forward 10 years...
>>
>> Nowadays Python has venv in the standard library. The user-specific
>> site-packages directory is no longer that useful.
>
> Can I disagree?
>
>> I would even say it's
>> causing more trouble than it's worth. For example it's common for system
>> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> System scripts are run under user root which seldom has user-specific
> site-packages so why worry?
You'd be surprised how many tools and programs are using Python these
> Hi!
>
> On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes <chri...@python.org> wrote:
>> Hi,
>>
>> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
>> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
>> virtual environment support in Python. Ian Bicking had just started to
>> create the virtualenv project a couple of months earlier.
>>
>> Fast forward 10 years...
>>
>> Nowadays Python has venv in the standard library. The user-specific
>> site-packages directory is no longer that useful.
>
> Can I disagree?
>
>> I would even say it's
>> causing more trouble than it's worth. For example it's common for system
>> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> System scripts are run under user root which seldom has user-specific
> site-packages so why worry?
days. You can easily break important user programs by installing a
package with --user.
Christian
Brett Cannon
Jan 13, 2018, 3:05:15 PM1/13/18
to Miro Hrončok, pytho...@python.org
On Sat, Jan 13, 2018, 11:13 Miro Hrončok, <mhro...@redhat.com> wrote:
On 13.1.2018 18:06, Christian Heimes wrote:
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
While I consider venvs easy and cool, this just moves the barrier for
the users a little bit higher. We (Fedora Python SIG) are fighting users
that run `sudo pip install` all the time (because the Interwebz are full
of such instructions). The users might be willing to listen to "please,
don't use pip with sudo, use --user instead". However, if you tell them
"learn how to use a venv", they'll just stick with sudo.
> I propose to deprecate the feature and remove it in Python 4.0.
We would very much like to see --user the default rather than having it
removed.
I concur with Miro. On VS Code we rely on people installing the e.g. linter of their choosing. We have been moving people away from sudo installs to user installs to minimize polluting the system Python (and we are doing what we can to promote venvs by using them automatically when present, but we can only do so much).
Basically the only way I see it being reasonable to drop user installs is if we move entirely to venvs for installs and I think that's probably too radical to work.
-Brett
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Christian Heimes
Jan 13, 2018, 3:08:19 PM1/13/18
to pytho...@python.org
to break system-wide programs.
These days a lot of packages are using setuptools' entry points to
create console scripts. Entry point have no option to create a console
script with -s or -I flag. On my system, only 40 out of 360 scripts in
/usr/bin have -s or -I.
Oleg Broytman
Jan 13, 2018, 3:09:30 PM1/13/18
to pytho...@python.org
On Sat, Jan 13, 2018 at 09:00:07PM +0100, Christian Heimes <chri...@python.org> wrote:
> On 2018-01-13 20:08, Oleg Broytman wrote:
> > Hi!
> >
> > On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes <chri...@python.org> wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> >> virtual environment support in Python. Ian Bicking had just started to
> >> create the virtualenv project a couple of months earlier.
> >>
> >> Fast forward 10 years...
> >>
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful.
> >
> > Can I disagree?
> >
> >> I would even say it's
> >> causing more trouble than it's worth. For example it's common for system
> >> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> >
> > System scripts are run under user root which seldom has user-specific
> > site-packages so why worry?
>
> You'd be surprised how many tools and programs are using Python these
> days.
Certainly not. I wrote or helped to write a lot of them myself. :-)
> On 2018-01-13 20:08, Oleg Broytman wrote:
> > Hi!
> >
> > On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes <chri...@python.org> wrote:
> >> Hi,
> >>
> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> >> virtual environment support in Python. Ian Bicking had just started to
> >> create the virtualenv project a couple of months earlier.
> >>
> >> Fast forward 10 years...
> >>
> >> Nowadays Python has venv in the standard library. The user-specific
> >> site-packages directory is no longer that useful.
> >
> > Can I disagree?
> >
> >> I would even say it's
> >> causing more trouble than it's worth. For example it's common for system
> >> script to use "#!/usr/bin/python3" shebang without -s or -I option.
> >
> > System scripts are run under user root which seldom has user-specific
> > site-packages so why worry?
>
> You'd be surprised how many tools and programs are using Python these
> days.
> You can easily break important user programs by installing a
> package with --user.
Python to import user-specific site-packages (i.e., distinguish system
Python from normal Python running under user root).
But for a non-root user user-specific site-packages is quite a
convenient thing. Please don't remove it.
> Christian
Oleg.
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
Antoine Pitrou
Jan 13, 2018, 3:14:36 PM1/13/18
to pytho...@python.org
On Sat, 13 Jan 2018 21:06:19 +0100
Christian Heimes <chri...@python.org> wrote:
> >>
> >> I see two option:
> >>
> >> 1) "pip install --user" is no longer supported. You have to learn how to
> >> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> >> install package".
> >> 2) "pip install --user" automatically creates or uses a custom virtual
> >> (~/.pip/virtualenv-$VERSION/) and links entry points to ~/.local/bin.
> >
> > Option 2 doesn't work, since the installed package then isn't known to
> > the system Python.
>
> I see that as a benefit. User installed packages will no longer be able
> to break system-wide programs.
I don't know if it's better or worse. I'm just saying it's not a
Christian Heimes <chri...@python.org> wrote:
> >>
> >> I see two option:
> >>
> >> 1) "pip install --user" is no longer supported. You have to learn how to
> >> use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip
> >> install package".
> >> 2) "pip install --user" automatically creates or uses a custom virtual
> >> (~/.pip/virtualenv-$VERSION/) and links entry points to ~/.local/bin.
> >
> > Option 2 doesn't work, since the installed package then isn't known to
> > the system Python.
>
> I see that as a benefit. User installed packages will no longer be able
> to break system-wide programs.
migration path from user site-packages since it doesn't have the same
semantics.
> These days a lot of packages are using setuptools' entry points to
> create console scripts. Entry point have no option to create a console
> script with -s or -I flag.
Regards
Antoine.
Steve Dower
Jan 13, 2018, 3:57:05 PM1/13/18
to Christian Heimes, pytho...@python.org
I’m generally +1, though I don’t see an easy migration path. Moving to a node.js project model might be feasible, but I suspect our real solution will end up having to be ensuring use of -s where it’s needed.
Top-posted from my Windows phone
Bruno Maximilian Voß
Jan 13, 2018, 4:35:13 PM1/13/18
to pytho...@python.org
Hi all,
I'm a user who decided to read the mailing list and respond to argue against and maybe stop things I don't think will help users as much as you think.I think deprecating user site-packages is such a change.Regards,
Max
Steven D'Aprano
Jan 13, 2018, 7:21:39 PM1/13/18
to pytho...@python.org
On Sat, Jan 13, 2018 at 09:00:07PM +0100, Christian Heimes wrote:
> You'd be surprised how many tools and programs are using Python these
> days. You can easily break important user programs by installing a
> package with --user.
Or by writing a Python script and innocently giving it the same name as
> You'd be surprised how many tools and programs are using Python these
> days. You can easily break important user programs by installing a
> package with --user.
a system module.
On the tutor@ and python-list@ mailing lists, it is very frequent for
users to accidently break Python by accidently shadowing an installed
module, e.g. installing xlrd and then calling their own script
"xlrd.py". But I've never come across somebody breaking anything by
installing a package with --user.
I presume it must happen, but I would be surprised if it happens often
enough to justify removing what is otherwise a useful piece of
functionality.
--
Steve
Alex Walters
Jan 13, 2018, 8:29:02 PM1/13/18
to pytho...@python.org
I would suggest throwing this to -ideas, rather than just keeping it in -dev
as there is a much wider community of users and usecases in -ideas.
... and -ideas will shoot it down because user installs are too useful. It
is also my understanding that it is the desire of PyPA to eventually have
pip default to --user when run outside of a virtualenv (to mitigate people
running sudo pip). Eliminating user installs would change the situation
from one where, with pip install --user, one can recoverably break their
system to one, with sudo pip install, one can un-recoverably break their
system.
> -----Original Message-----
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamo...@python.org] On Behalf Of Christian Heimes
> Sent: Saturday, January 13, 2018 12:06 PM
> To: pytho...@python.org
> Subject: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?
>
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> list%40sdamon.com
as there is a much wider community of users and usecases in -ideas.
... and -ideas will shoot it down because user installs are too useful. It
is also my understanding that it is the desire of PyPA to eventually have
pip default to --user when run outside of a virtualenv (to mitigate people
running sudo pip). Eliminating user installs would change the situation
from one where, with pip install --user, one can recoverably break their
system to one, with sudo pip install, one can un-recoverably break their
system.
> -----Original Message-----
> From: Python-Dev [mailto:python-dev-bounces+tritium-
> list=sdamo...@python.org] On Behalf Of Christian Heimes
> Sent: Saturday, January 13, 2018 12:06 PM
> To: pytho...@python.org
> Subject: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?
>
> list%40sdamon.com
Brett Cannon
Jan 13, 2018, 9:30:19 PM1/13/18
to Alex Walters, pytho...@python.org
On Sat, Jan 13, 2018, 17:27 Alex Walters, <tritiu...@sdamon.com> wrote:
I would suggest throwing this to -ideas, rather than just keeping it in -dev
as there is a much wider community of users and usecases in -ideas.
... and -ideas will shoot it down because user installs are too useful. It
is also my understanding that it is the desire of PyPA to eventually have
pip default to --user when run outside of a virtualenv (to mitigate people
running sudo pip). Eliminating user installs would change the situation
from one where, with pip install --user, one can recoverably break their
system to one, with sudo pip install, one can un-recoverably break their
system.
Which suggests that doing away with user installs would mean making it so interpreter installs don't break your system, which would require Linux and distros and macOS to not publicly expose their system Python installs so people can't accidentally break them. I think if that were to occur then you could consider dropping user installs as people would be installing into their own interpreter. But until then I think the attraction/lack of knowledge for people will be high enough that user installs will be the most pragmatic solution we have.
-Brett
Barry Warsaw
Jan 13, 2018, 10:15:59 PM1/13/18
to Python Dev
On Jan 13, 2018, at 11:12, Miro Hrončok <mhro...@redhat.com> wrote:
>
> We would very much like to see --user the default rather than having it removed.
Very much +1. In Debian/Ubuntu we’ve carried patches to do exactly that for years, and I think our users have been very happy about it.
>
> We would very much like to see --user the default rather than having it removed.
-Barry
Barry Warsaw
Jan 13, 2018, 10:18:34 PM1/13/18
to Python Dev
On Jan 13, 2018, at 12:06, Christian Heimes <chri...@python.org> wrote:
> These days a lot of packages are using setuptools' entry points to
> create console scripts. Entry point have no option to create a console
> script with -s or -I flag. On my system, only 40 out of 360 scripts in
> /usr/bin have -s or -I.
-I should be the default for system scripts; it’s not on Debian/Ubuntu though unfortunately.
> These days a lot of packages are using setuptools' entry points to
> create console scripts. Entry point have no option to create a console
> script with -s or -I flag. On my system, only 40 out of 360 scripts in
> /usr/bin have -s or -I.
-Barry
Toshio Kuratomi
Jan 13, 2018, 11:02:35 PM1/13/18
to Christian Heimes, Python-Dev
On Jan 13, 2018 9:08 AM, "Christian Heimes" <chri...@python.org> wrote:
Hi,
PEP 370 [1] was my first PEP that got accepted. I created it exactly one
decade and two days ago for Python 2.6 and 3.0.
I didn't know I had you to thank for this! Thanks Christian! This is one of the best features of the python software packaging ecosystem! I almost exclusively install into user site packages these days. It lets me pull in the latest version of software when I want it for everyday use and revert to what my system shipped with if the updates break something. It's let me I install libraries ported to python3 before my distro got stopping to packaging the updates. It's let me perform an install when I want to test my packages as my users might be using it without touching the system dirs. It's been a godsend!
Fast forward 10 years...
Nowadays Python has venv in the standard library. The user-specific
site-packages directory is no longer that useful. I would even say it's
causing more trouble than it's worth. For example it's common for system
script to use "#!/usr/bin/python3" shebang without -s or -I option.
With great power comes great responsibility...
Sure, installing something into user site packages can break system scripts. But it can also fix them. I can recall breaking system scripts twice by installing something into user site packages (both times, the tracebacks rapidly lead me to the reason that the scripts were failing). As a counter point to that I can recall *fixing* problems in system scripts by installing newer libraries into site packages twice in the last two months. (I've also fixed system software by installing into user and then modifying that version but I do that less frequently... Perhaps only a couple times a year...)
Removing the user site packages also doesn't prevent people from making local changes that break system scripts (removing the pre-configuration of user site packages does not stop honoring usage of PYTHONPATH); it only makes people work a little harder to place their overridden packages into a location that python will find and leads to nonstandard locations for these overrides. This will make it harder for people to troubleshoot the problems other people may be having. Instead of asking "do you have any libraries in .local in your tracebacks?" as an easy first troubleshooting step. Without the user site packages standard we'll be back to trying to determine which directories are official for the user's install and then finding any local directories that their site may have defined for overrides....
I propose to deprecate the feature and remove it in Python 4.0.
Although I don't like the idea of system scripts adding -s and -l because it prevents me from fixing them for my own use by installing just a newer or modified library into user site packages (similar to how c programs can use overridden libraries via ld_library_path), it seems that if you want to prevent users from choosing to use their own libraries with system scripts, the right thing to do is to get changes to allow adding those to setuptools and distutils. Those flags will do a much more thorough job of preventing this usage than removing user site packages can.
-Toshio
Christian Heimes
Jan 14, 2018, 8:48:50 AM1/14/18
to pytho...@python.org
Same for most Fedora scripts. :/
Christian
Nick Coghlan
Jan 14, 2018, 9:40:58 AM1/14/18
to Christian Heimes, python-dev
On 14 January 2018 at 03:06, Christian Heimes <chri...@python.org> wrote:
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> I propose to deprecate the feature and remove it in Python 4.0.
Given that we're working towards making user site-packages the default
> Hi,
>
> PEP 370 [1] was my first PEP that got accepted. I created it exactly one
> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have
> virtual environment support in Python. Ian Bicking had just started to
> create the virtualenv project a couple of months earlier.
>
> Fast forward 10 years...
>
> Nowadays Python has venv in the standard library. The user-specific
> site-packages directory is no longer that useful. I would even say it's
> causing more trouble than it's worth. For example it's common for system
> script to use "#!/usr/bin/python3" shebang without -s or -I option.
>
> I propose to deprecate the feature and remove it in Python 4.0.
install location in pip, removing that feature at the interpreter
level would be rather counterproductive :)
Virtual environments are a useful tool if you're a professional
developer, but for a lot of folks just doing ad hoc personal
scripting, they're more complexity than is needed, and the simple "my
packages" vs "the system's package" split is a better option. (It's
also rather useful for bootstrapping tools like "pipsi" - "pip install
--user pipsi", then "pipsi install" the other commands you want access
to).
Cheers,
Nick.
--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
Reply all
Reply to author
Forward
0 new messages