Re: [Distutils] formencode as .egg in Debian ??
Ian Bicking wrote:
> M.-A. Lemburg wrote:
>
>>> Eggs give room for package metadata that doesn't exist otherwise.
>>> Putting dependencies aside, this is functionality that simply doesn't
>>> exist with the standard distutils installation. In the case of
>>> FormEncode, it doesn't make use of any egg features (except that other
>>> packages may want to depend on it using setuptools). In the case of
>>> other frameworks -- including TurboGears (which I think is the ultimate
>>> packaging goal here) -- the Egg metadata really is important, it's not
>>> just used for dependencies.
>>
>>
>>
>> Understood, but wouldn't it be reasonably possible to
>> also install this meta-data into a standard site-packages
>> package directory ?
>
>
> An egg and Python packages don't map 1-to-1. An egg can contain
> multiple packages (which is fairly uncommon so far), but also a
> top-level package can exist in more than one egg (i.e., namespace
> packages, like zope.interfaces or paste.script). The metadata belongs
> to the egg, not to the package inside the egg.
>
> Also, some of the metadata is encoded in the directory name itself, like
> the version information. I think this makes it easier to do some
> scanning operations, without a single database of installed packages
> (and also respecting sys.path manipulation).
Well, yes, but all of this is only needed for the egg support.
In order to keep compatibilty with the existing wide-spread
approach to install packages in site-packages/ using "python setup.py
install", it should be possible (and I believe this should be the
default to not disrupt existing usage and documentation) to
run "python setup.py install" with an eggified source
distribution in addition to the command to install it as
regular egg.
Otherwise, we'll end up with completely confused users
and two disjoint and incompatible installations mechanisms.
> That said, I think it would be nice if the transition was smoother.
> E.g., if a file "ElementTree-1.2.6.egg-provided" could point to an
> installed elementtree library (similar to the currently-supported
> .egg-link file, but also slightly different). And, perhaps,
> elementtree/ElementTree.egg-info could exist (with the same data as the
> current ElementTree-1.2.6/EGG-INFO), though I think the simpler case
> where extra metadata is disallowed would be easier. That would only
> work for situations when there's a 1-to-1 mapping from packages to
> eggs/projects, but that covers many situations, especially cases where
> we're currently seeing conflicts. You lose the ability to easily
> support multiple versions of a package with this, though that could
> probably be handled too.
I'm not suggesting to port over all the features you
get from using setuptools' eggs (even though I do believe
that you can go a long way using a special egg import
hook), but it should be possible to get a regular working
installation using "python setup.py install".
PS: I understand setuptools and eggs as feature set which
adds functionality to distutils, not as competitive
and disjoint all-in-one solution. The latter won't fly
well with installations that require native installers
to be used such as Debian's apt-get, rpm and all
the others.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 22 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Reply to: