[Distutils] setuptools: package management and explicit version numbers
Phillip J. Eby
pje at telecommunity.com
Thu Aug 11 17:29:48 CEST 2005
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
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
>(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.
More information about the Distutils-SIG