[Python-Dev] PEP 365 (Adding the pkg_resources module)

[Steve Holden]

Martin v. Löwis wrote:
Martin v. Löwis wrote:
>> I'll note that I use easy_install *only* to work in *non-system*
>> locations:  if I want to install Python packages to /usr/lib/python2.x/,
>> I use the standard system installer, e.g. 'apt-get install
>> python-frobnatz'. 
> 
> This is probably not the Windows way of doing things (at least not how
> I use Windows). Windows doesn't really have the notion of "system
> location" (or multiple levels of them, where \Windows and 
> \Windows\system32 is "more system" than \Program Files, say).
> 
> Windows users typically view the entire system as "theirs", and
> have no concerns at all about putting things into Program Files,
> system32, or, for that matter, \python25. In fact, they don't care
> or even know where stuff ends up - they expect that the system will
> find it, and they expect that they can remove anything they installed
> even without known where it is - because there is a standard place
> to look for uninstalling things.
> 
> Of course, setuptools is not the only piece of software that doesn't
> play well, so Windows users collect all kinds of cruft over time.
> Eventually, C: will run out of disk space, and they either get a
> new machine, or reinstall from scratch.
> 
>> I wonder if a GUI for managing the add-ons would fit the bill, as an
>> alternative to packaging them as though they were standalone programs?
> 
> On Windows, it is fairly easy to have an uninstaller registered. There
> are wrappers to managing that (such as MSI), but it's really only a
> set of registry keys that needs to get written on installation time,
> one of them being the command to run on uninstallation.
> 
> Assuming that you uninstall the package before uninstalling Python, that
> uninstall program could be a Python script (although using a cmd.exe
> batch file would probably be more resilient).
> 
> The concern with "you just need to delete the folder" is "how am I
> supposed to know that? and can I be really sure?". If you run the
> official uninstall procedure, and it messes things up, you can complain
> to setuptools, or the package author that uninstallation "doesn't work".
> 
> If you delete stuff manually, and you forgot to remove something in
> a remote location you didn't even know it existed, you still think
> it's your own fault. So people are hesitant to actually execute the
> procedure.
> 
> Of course, once you *do* provide an entry to "Add/Remove Programs",
> uninstalling won't be mere deletion, as mere deletion would still
> leave these registry keys behind (although Windows got more resilient
> over time to provide cleanup in that case: I believe it offers to
> remove the ARP entry if the uninstall program has been removed)
> 
> 
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
> 

>> I'll note that I use easy_install *only* to work in *non-system*
>> locations:  if I want to install Python packages to /usr/lib/python2.x/,
>> I use the standard system installer, e.g. 'apt-get install
>> python-frobnatz'. 
> 
> This is probably not the Windows way of doing things (at least not how
> I use Windows). Windows doesn't really have the notion of "system
> location" (or multiple levels of them, where \Windows and 
> \Windows\system32 is "more system" than \Program Files, say).
> 
> Windows users typically view the entire system as "theirs", and
> have no concerns at all about putting things into Program Files,
> system32, or, for that matter, \python25. In fact, they don't care
> or even know where stuff ends up - they expect that the system will
> find it, and they expect that they can remove anything they installed
> even without known where it is - because there is a standard place
> to look for uninstalling things.
> 
In point of fact, for an *end user* it makes increasing sense to use 
application installers that automatically install a correct-version 
interpreter and all dependencies in a stand-alone manner (i.e. 
explicitly *not* sharing anything with any other installed application.

This makes uninstall much easier, as the lack of external dependencies 
eases version lock-step problems.

It would pain me, as a computer scientist, to do this, but I honestly 
believe it may be the way forward -- just think, it wouldn't even matter 
whether an application (and all its extension modules) had been built 
with VS2003, VS2008 or Mingw.

People misunderstood when Mike Driscoll started to provide pure-Python 
modules as Windows installers, but increasingly your naive Windows 
programmer is going to be happier doing that. I'm not sure whether that 
provides easy_f**king_uninstall (Zed Shaw will live on in my memory for 
that particular PyCon moment), but it (ought to be) relatively easy to 
do so. Extension modules for programmers still offer more of a 
challenge, but a build-farm for extension module writers could help there.

> Of course, setuptools is not the only piece of software that doesn't
> play well, so Windows users collect all kinds of cruft over time.
> Eventually, C: will run out of disk space, and they either get a
> new machine, or reinstall from scratch.
> 
As someone who just gave away a Windows laptop because I'd become sick 
of the sight of it I sing amen to that.

>> I wonder if a GUI for managing the add-ons would fit the bill, as an
>> alternative to packaging them as though they were standalone programs?
> 
> On Windows, it is fairly easy to have an uninstaller registered. There
> are wrappers to managing that (such as MSI), but it's really only a
> set of registry keys that needs to get written on installation time,
> one of them being the command to run on uninstallation.
> 
> Assuming that you uninstall the package before uninstalling Python, that
> uninstall program could be a Python script (although using a cmd.exe
> batch file would probably be more resilient).
> 
> The concern with "you just need to delete the folder" is "how am I
> supposed to know that? and can I be really sure?". If you run the
> official uninstall procedure, and it messes things up, you can complain
> to setuptools, or the package author that uninstallation "doesn't work".
> 
I quite agree. I believe it might help if we clearly distinguished 
between "developer install", to add required functionality to a specific 
Python installation (and here distutils is almost good enough, 
setuptools begins to seem like overkill), and "application install" to 
add a bundle of executable functionality to a computer for an end-user.

> If you delete stuff manually, and you forgot to remove something in
> a remote location you didn't even know it existed, you still think
> it's your own fault. So people are hesitant to actually execute the
> procedure.
> 
> Of course, once you *do* provide an entry to "Add/Remove Programs",
> uninstalling won't be mere deletion, as mere deletion would still
> leave these registry keys behind (although Windows got more resilient
> over time to provide cleanup in that case: I believe it offers to
> remove the ARP entry if the uninstall program has been removed)
> 
We need to stop protesting that our installation tools are easy enough 
and try to get behind the various platforms, be it with Windows 
installers, rpms, or other support. We probably aren't doing this 
because it's work nobody particularly relishes, and has relatively low 
visibility in the developer world. Non-developer Python programmers and 
end-users would thank us, though.

regards
  Steve