[Distutils] PEP 365 (Adding the pkg_resources module)

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Moore wrote:

> I'll chime in here, too. I really want to like
> setuptools/easy_install, but I don't. I'll try to be specific in my
> reasons, in the hope that they can be addressed. I know some of these
> are "known about", but one of my meta-dislikes of setuptools is that
> known issues never seem to get addressed (I know, patches accepted,
> but I haven't got the time either...)

Thanks for feedback from the Windows world, from whence I have been
blissfully exiled now for years.

> 1. No integration with the system packager (Windows, in my case). If I
> do easy_install nose, then nose does not show up in add/remove
> programs. That significantly affects the way I manage my PC.

Point taken. Of course, it isn't really a "program" at that point:  it
is an installed "add-on" to Python.  However, if Windows users expect
such add-ons to show up in the "system" list, that is good to know.

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'.  But I routinely create non-system Python environments
for development, using either alternate Pythons or virtualenv:  in those
environments, it works very well for me.

> 2. No uninstaller. After easy_install nose, how do I get rid of it
> later? Searching for files to delete (even if there are only a few
> obviously named ones) is not good enough.

People ask for this on Unix platforms as well, often adding a request
that pacakges installed only as dependencies of the
package-being-removed go away as well.  If you install everything in a
way that works with system package manager, of course, you don't need
this. ;)

Deleting the 'lib/python2.x/site-packages/foo-X.Y.X.egg' directory is
all that is actually required to uninstall an egg that was previouly
added via easy_install.  Cleaning out the equivalent entry in
'easy_install.pth' in that directory is not strictly required.

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?

> 3. The pkg_resources documentation (in particular, that's the one I've
> tried to follow) is extremely hard to read. Partly this is just style,
> but it's partly because it is couched in very unfamiliar terms
> (distributions, working sets, interfaces, providers, etc). It's also
> *huge*. A tutorial style overview, supported by API detail, would be
> far better.

Many of those terms are distutils jargon, actually.  I think Jeff Rush'
recent work looks like a good start here.

> 4. Hard to use with limited connectivity. At work, I *only* have
> access to the internet via Internet Explorer (MS based proxy). There
> are workarounds, but ultimately "download an installer, then run it"
> is a far simpler approach for me.

I don't know how to make this requirement compatible with using shared
dependencies, except to make it easier for folks to download *all* the
requirements, and later install from the local "distribution cache" (a
directory full of .zip / .egg / .tgs files).  It does turn out to be
quite easy to build a PyPI-style "simple" index for such a cache.  Your
use case would then require:

 1. Run some command to fetch the desired package and the transitive
    closure of its dependencies into a working directory (the cache).

 2. Run another command to build an index for that directory.

 3. Run 'easy_install', pointing to the local index.

> 5. Auto-discovery doesn't always work. I'm sorry, I really can't
> recall the example at the moment, but sometimes easy_install says it
> can't find a package I *know* is available.

Usually this indicates that there are incompatible dependencies between
packages already installed and those on the index.  E.g., if I already
have package foo installed, but its version is not compatible with the
requirements for package bar, then I can't install bar, even though the
distribution is "available."

Because PyPI is not a centrally-managed index of packages, such
conflicts are pretty much inevitable over time for those who don't
subset it in some form (what we've been calling the "known good set"
strategy in Zope-land).

> 6. Splitting the community. Windows users rely heavily on binary
> installers (at least, I do). We're starting to get a situation where
> some projects provide .egg files, and some provide traditional
> (bdist_wininst/bdist_msi) installers. This is bad. One way to do it,
> and all that :-)

If it weren't for the "Add / Remove Programs" requirement you mentioned
above, we would be better off if authors of pure Python packages
uploaded only 'sdist' distributions, which can be cleanly converted to
platform-local eggs at install time, even on Windows.  Packages which
contain C extensions typically must upload the 'bdist_win' version for
the benefit of the vast majority of Windows users who can't bulid the
extensions locally.

Uploading any other binary distribution is pretty much a lose, because
the underlying platform dependencies (UCS2 vs UCS4, i386 vs x64,
framework vs. universal vs. MacPorts vs. Fink, etc) lead to
combinatorial expolosions and or segfaults.   Better to let the
installer fetch the source and build it locally.

> But if these problems are solved, then I have no problem with seeing
> the features of setuptools added to the standard library - resource
> APIs, plugin/entry point APIs, ways to create executable scripts, and
> such things *should* be standardised. Dependency resolution and
> automatic installation isn't something I like (probably because as a
> Windows user I've never used such a system, so I mistrust it) but if
> it works *with* the system and not against it, I don't mind.
> 
> I hope this helps,

Very much, thanks.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH4mof+gerLs4ltQ4RApBLAJwI0Be1CtSKgpAYDEyH2qd0K+a+6QCeN/cf
5Pg43ot4H954A87ZWIouwLo=
=S4yF
-----END PGP SIGNATURE-----