On Fri, Jul 19, 2013 at 5:29 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 19 July 2013 05:23, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 July 2013 09:37, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
I think the point is that people might be dependent on this functionality and
changing it out from underneath them could break their world.
I got the point that Daniel made, and my question was about *how* their world would break, and whether we really need to support multiple versions of something installed side-by-side, with on-the-fly sys.path manipulation. If that is a real requirement which should be supported, shouldn't there be a PEP for it, if it's coming into Python? It's not supported by distutils, and it has been a point of contention.
It's a real requirement - Linux distros need it to work around parallel installation of backwards incompatible libraries in the system Python. Yes, it's an implementation defined feature of pkg_resources (not setuptools per se), but it's one that works well enough even if the error message can be opaque and the configuration can get a little arcane :)
Just to be absolutely clear on my interest in this:
1. I believe (but cannot prove, so I'll accept others stating that I'm wrong) that many people using setuptools for the console-script entry point functionality, have no specific interest in or requirement for multi-version. As an example, take pip itself. So while it is true that functionality will be lost, I do not believe that users will actually be affected in the majority of cases. That's not to say that just removing the functionality without asking is valid.
2. Projects typically do not declare a runtime dependency on setuptools just because they use script wrappers. Maybe they should, but they don't. Again, pip is an example. So wheel-based installs of such projects can break on systems without setuptools (pkg_resources). This is going to be a bigger problem in future, as pip install from wheels does not need setuptools to be installed on the target (and if we vendor setuptools in pip, nor does install from sdist). Of course, after the first time you hit this, you install setuptools and it's never a problem again. But it's a bad user experience.
3. It's an issue for pip itself, as we explicitly do not want a dependency on a system installed setuptools. So we have to hack or replace the setuptools-generated wrappers.
Paul.
pip should just add pkg_resources as a dependency for any package that has console_scripts entry points.