[Distutils] Unravelling installation schemes

[Mark W. Alexander]

On Wed, Mar 10, 2004 at 11:29:58AM -0500, Phillip J. Eby wrote:
> >If Distutils can make binary packages for most package managers, and it
> >can be extended to include "Provides" and "Requires" in the meta-data,
> >then any OS's native package manager should have all the information it
> >needs to do the right thing at install time.
> 
> Well, it sounds like you have more experience with those package managers 
> than I do, so it would be helpful if you could lay out a plan for this with 
> sufficient detail to at least allow me to contemplate implementing it.

Somewhere I built a table mapping PEP 241 metadata to RPM, SD-UX (HP's
manager), and pkgtool (Solaris). I could probably add dpkg now that I've
got some experience there. (My HP is slowly rusting, but I still have
code I can read.)

> >Why does everyone seem to think that the prefered method of Distutils
> >package installations is "setup.py install"?
> 
> Er, perhaps because they prefer it?  :)  I know I do.

It's fine if you're only concerned about a machine or 2. If you've got
several, having software managed by the native package manager is the
ony thing that will keep you sane.

> > What's the point of
> >providing bdist_* commands if we're going to perpetualy re-inforce the
> >"setup.py install" mindset? I'm not trying to be confrontational here,
> >but do we seriously expect everyone who wants to install Distutils
> >packages to have a compiler suite in case a package has C extensions?
> 
> That's why I want the dependency system to support installing binary 
> packages as dependencies, at least on Windows.

OK. I got distracted by your discussion of install commands and didn't
see anything regarding binary packages.

> >Even without C extensions, I suspect you can rule out most Windows users
> >by just telling them to "setup.py install". You'll be lucky if you can
> >get them to listen long enough when they ask you to explain how to pass
> >"install" as an option when they click the setup.py icon.
> 
> Uh, wouldn't you be supplying your application to those people as a py2exe 
> or other installable with all its dependencies self-contained?

Actually, Windows is my weakest platform (sorry, no apologies either ;)
I don't know how py2exe works, but I'd prefer a method where
dependencies where resolved externally so every package that might
require package X doesn't have to include package X. A Windows installer
that could download and install dependencies would be nice.

> >I really, really, think Distutils should _produce_binary_packages. For
> >as many platforms and package managers as possible, with as much
> >meta-data as each package manager supports.
> 
> Fantastic, so we can count on your support for specifying what metadata is 
> needed in a way that will work with all these package managers?  :)

Absolutely! As I said, I had a decent start of an abstract packager used
by implementations of bdist_pkgtool and bdist_sdux. I use them in-house,
but my employer has not granted me permission to provide the Python
Software Contributor agreement required for them to be included.

If _anyone_ is interested. contact be off-line and I'll provide a
detailed descriptiong that would allow a clean-room re-write.

> Keep in mind that many developers don't have a clue about these package 
> managers, perhaps not even the one for the system they use!  If distutils 
> requires the developer to understand every packaging system in order to 
> release a package, it's useless.

This much is certain. Packaging is almost a distinct art from coding.
Based on what I've done, and what I see that Marc has done with the
Egenix packages, I think almost everything that's needed is in place.
The only thing possibly missing is "requires" and "provides", and it's
been so long since I reviewed a PEP, they may be there for all I know.

> However, if all the information needed for packaging can be described in 
> setup.cfg, I imagine most developers would accept patches from people with 
> packaging tool experience to add metadata for the various package 
> managers.

I think it's easier than that. There should be almost no difference in
the actual metadata required by the different package managers out
there. They just use different names for the fields. 

> Even then, I'm not sure how workable it is, given that dependencies
> would now need to include many more URLs for where to get all the
> differently-packaged versions of the packages.

Couldn't that be handled simply by each bdist_tool knowing how the
package-name maps to the binary package name. Different package
manager's all have different naming conventions, even if it's only a
different extension.

mwa
-- 
Mark W. Alexander
slash at dotnetslash.net

The contents of this message authored by Mark W. Alexander are
released under the Creative Commons Attribution-NonCommercial license.
Copyright of quoted materials are retained by the original author(s).

http://creativecommons.org/licenses/by-nc/1.0/