[Distutils] setuptools: package management and explicit version numbers

[Ian Bicking]

Paul Moore wrote:
> On 8/10/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> 
>>At 01:00 PM 8/10/2005 -0500, Ian Bicking wrote:
>>
>>>Has there been any progress on some of the package management tools
>>>people were talking about?  I.e., list and delete packages?  (At the
>>>moment no other features come to mind, but I'm definitely seeing a
>>>purpose for these functions)  Someone said they were going to give it a
>>>go, but I can't remember who.
>>
>>It was Paul Moore.
> 
> 
> It was indeed. I haven't forgotten, but a number of things have kept
> me from making progress yet. The first is the usual lack of time, but
> that's not a limiting factor here, really. I've also been waiting for
> the reorganisation of the API that Phillip promised, but again that's
> not a real problem - I can use CVS if I need to.
> 
> My main issue is one of perspective, I guess. I'm not a package
> maintainer, so much of the setuptools stuff (resource APIs, entry
> points etc, etc) is not directly relevant to me. I'm a package *user*,
> and so my viewpoint is of eggs as an alternative to Windows
> bdist_wininst installers.
> 
> Hence my interest in management tools - installers come with a number
> of benefits "free", as part of the Windows installer architecture -
> you get an uninstall "command", you can see a listing of installed
> packages, and you can see the version numbers of those packages. Until
> I can do the same with eggs, they are a step backwards for me. So
> that's why I want to build these features.

I suspect the management tool has two parts -- one is extending 
pkg_resources so these operations are easy (list, delete).  Then you 
want to integrate that into Windows' installer architecture -- 
registering the packages and uninstallers with Windows, maybe making a 
GUI frontend (though you could almost get away without it).  But since 
I'm not using Windows, the frontend I imagine is obviously very 
different.  My frontend is probably really easy, but I have no idea what 
a GUI frontend would entail.

> OK, so given that I have to write some code to bring eggs onto a par
> with installers, where's the benefit of eggs, *to me*, which would
> make me want to switch to them in the first place? And that's where I
> get stalled. I can see lots of benefits to eggs - for example Trac's
> new feature allowing you to just drop an egg containing a plugin into
> a predefined directory is really exciting - but they don't apply to my
> simple requirement to install packages like cx_Oracle, pywin32,
> ctypes, Cheetah, into my standard Python installation.

I think eggs are sometimes a distraction when considering features.  Or 
at least they are for me.  I know there's some eggs produced when I 
install stuff with easy_install, but I don't really touch them or care 
about them much.  Right now I don't have any incentive to distribute 
anything but source packages (from sdist); easy_install and setuptools 
do a fine job of using these, and for the users I interact with (other 
programmers) the source package is more usable.

But anyway, the feature for me is the installation of different package 
versions.  This makes me less worried about installing things globally. 
  This in turn makes management a lot easier.

I suspect Windows usage patterns (or just your patterns) aren't the 
same, so you aren't as concerned about this.

Another issue is installation of dependencies.  This is still just 
potential for me; I haven't really had the satisfying experience of 
getting a package to install lots of dependencies for me.  But I think 
I'm getting closer.  This is something I'm used to with software 
installation, but not Python.  Windows doesn't do this anyway, so you 
probably aren't clamouring for it.  I think it changes the larger 
ecosystem and encourages sharing; but the payoff isn't as immediate 
because there isn't as much sharing as there could be.

And last is formal metadata on a package, which is what makes plugins 
workable.  You'll only see this as people actually start using that 
metadata, so there's not much appeal there yet.

> This is more than just a philosophical issue, in that a lot of the egg
> infrastructure (development installs, for example) don't seem to me to
> be relevant to the end user scenario. So, from my perspective, I don't
> understand the imperatives which make them useful, and consequently I
> can't do a good job of designing list/uninstall commands around them.
> And I have no need for the facilities, so no incentive to cater for
> them (beyond the desire to do a good job...)

The development installs are there for developers.  Software doesn't 
appear out of thin air!

> Ian - how this fits in with your requirements, I'm not sure. I really
> don't follow your comments at all well, as I don't have the relevant
> background (at the level I develop stuff, the prerequisite version
> compatibility issues you describe just don't come into it - I only
> distribute to a very limited set of targets, all of which are closely
> controlled in terms of what is installed, so I have the luxury of
> expecting things to "just work"). It's on my list of things to do, to
> go back over the various recent postings and try to understand the
> developer perspective better. But I still view the end-user side of
> things as the first priority.

I'm not surprised most of my comments haven't made sense to you -- I'm 
just plodding along and trying to figure details out.  I'm hoping when I 
get all the details figured out that the larger picture will make more 
sense to me, but I haven't quite gotten there yet.  Mostly in terms of 
how this stuff *should* be used, as opposed to how it *can* be used. 
Plus you only see my questions so far, anything I understand I've kept 
to myself ;)

I'm doing a presentation on this stuff tomorrow, though, so hopefully 
I'll get closer today.  It'll feature lots of command-line transcripts 
you probably will find rather unexciting ;)


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org