[Distutils] setuptools: package management and explicit version numbers

[Phillip J. Eby]

At 10:40 AM 8/11/2005 +0100, Paul Moore wrote:
>there's a transitional problem with bdist_wininst installers, which
>needs some thinking about (and no, easy_install's "convert a wininst
>installer to an egg" feature isn't an answer - it loses things like
>cx_Oracle's documentation,

FYI, if there's a source distribution, the new --editable option (in CVS) 
allows you to download and extract the source for editing, without building 
it or anything.


>  and I suspect that it breaks horribly for
>pywin32, which uses a postinstall script).

Hm.  It's true that I haven't done anything to handle postinstall scripts; 
but I was under the impression that pywin32 self-registers when you try to 
use it.  I'll have to look into that.

I could probably actually add postinstall hooks to EasyInstall, except that 
it sort of goes against the concept of eggs being a "zero install" 
format.  It's worth thinking about/investigating though.


>As this issue is transitional only, it's not the end of the world, as
>long as eggs really do become the package distribution medium of
>choice for Python. I'd like to see some sign that eggs are making
>inroads against bdist_wininst, first, though.

That's not going to happen real soon; only a relatively tiny number of 
people even know eggs exist, and as long as they have a reasonably-usable 
bdist_wininst available then it's certainly a valid choice to just 
distribute that, thereby pleasing EasyInstall users and non-users alike.


>So unless you are building packages with C extensions having complex
>build requirements, you'll get no incentives from me - the source
>package is fine. But I'll use it to build Windows installers, and
>never bother with eggs.

Some packages of course may be eventually only be distributed as eggs.  For 
example, I'm switching all of my win32 binary distributions to eggs, which 
means you'll have to compile from source if you want a bdist_wininst.  But 
I'm likely to be in the minority for some time to come.  Transitions like 
this don't happen overnight, especially not based on an 0.6 alpha 
infrastructure.  :)


>(Is there ever going to be a situation where code *won't work" unless
>run from an egg?

Plugins, definitely.  And over time, the definition of what constitutes a 
"plugin" is likely to be ever-expanding.  For example, setuptools now 
supports plugins to add distutils commands, setup() arguments, and so 
on.  The *only* way to leverage these features is with an egg, even if it's 
a "development-mode" egg.


>  I can see that being an issue, unless there's a way
>availabe to wrap eggs in Windows installers, RPMs, debs, etc

There is in principle, but the respective bdist commands would need some 
updating in order to work that way.  Currently, you'd have to run 
EasyInstall first, and then package the resulting egg file or directory 
tree.  This is an area that needs some actual tool development, to produce 
some scripts like 'egg2rpm', 'egg2wininst', etc.  Or better yet, setuptools 
should probably grow replacement bdist commands, although these could also 
be distributed as extension eggs at first.


>Agreed, and I understand the benefits. But I don't have the experience
>to understand the trade-offs and/or risks, so I have to be very
>cautious in what I promise. (For example, if I code an "uninstall"
>command, and someone runs it on a development install, does that
>delete all of that person's working code? How can I make sure that
>doesn't happen without breaking the "normal" uninstall functionality?

Don't delete anything that's not in the directory or directories your tool 
is managing.  Development installations are outside the normal 
site-packages area, and deleting the '.egg-link' file from the 
site-packages directory "uninstalls" it.