[Distutils] Unravelling installation schemes

[Phillip J. Eby]

At 08:44 PM 3/9/04 -0500, Mark W. Alexander wrote:
>On Tue, Mar 09, 2004 at 06:57:49PM -0500, Phillip J. Eby wrote:
> > I guess I'm beginning to see why nobody else has tackled this up to 
> now.  :)
>
>My $.02 is, Distutils can take one of 2 forms. It can be
>automake/autoconf for Python and everyone can install from source, or it
>can be a package manager. The battle you're fighting seems to me to be
>from trying to make it do both.

Actually, it has a lot more to do with the path munging that the 'install' 
command does, which doesn't preserve a lot of the information in question, 
coupled with the fact that I'm producing a separate package, rather than 
hacking the distutils source directly.


>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.


> > Of course, for maybe half the installs it would suffice to just run
> > 'setup.py install' on the dependencies.  For about half of the remaining
> > situations, it would probably suffice to just pass along whatever options
> > were specified on the parent setup script's command line, verbatim.
>
>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.


>  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.


>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?


>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?  :)

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.

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.  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.