Re: [Distutils] formencode as .egg in Debian ??
On Fri, 2005-11-25 at 08:57 -0500, Phillip J. Eby wrote:
> At 10:29 AM 11/25/2005 +0000, Donovan Baarda wrote:
> >On Fri, 2005-11-25 at 01:33 -0500, Phillip J. Eby wrote:
[...]
> In the case where the user is *not* using easy_install, then all
> dependencies will be met by system packages, and the only "duplication" is
> that the paranoid setuptools integrity-check wrappers will want to be
> assured that yes, everything is still there.
[...]
> If you are running easy_install or setup.py to install TurboGears, and an
> egged ElementTree is not available, one is going to get installed for you
> -- because in that scenario you are asking for installation and are
> presumably doing it to /usr/local or to ~/somewhere. If you are merely
> *using* TurboGears and an egged version of a dependency is not available,
[...]
> Right; the point here is that if somebody is going *outside* of Debian
> packages and explicitly using setup.py or easy_install to install it, then
> it would be nice for them to *still* be able to use system packages to meet
> some of the dependencies, rather than having to re-download, re-build, and
> re-install new copies of the stuff they already have. This isn't about
> changing Debian to support bleeding edge things, it's about allowing people
> doing bleeding edge things to not need to duplicate what Debian already
> provides.
I'm not sure at this point whether you are describing the way eggs
currently work, or the way you have figured out they should work to
behave nice with Debian... it sounds OK to me :-)
> >I think they a both important. If I was using eggs, I'm not sure I'd
> >want them to be packaged as anything other than an egg until I was ready
> >to release, and then I'd want it **not** packaged as an egg, as a "proof
> >of it's release readiness".
>
> Well, that would only work if you weren't developing something using entry
> points to tie an extensible application or framework together. And that
> didn't use egg metadata for anything else. But if all you used it for was
I was referring here to stripping the egg package management "layer".
> >It's perhaps unfortunate that egg's bundle package management with
> >generic meta-data management.
>
> It's not really bundled - integrity checking and inter-package linking do
> not a package manager make. EasyInstall is the (rather primitive) package
> manager, and it only comes into play if you are manually installing
> things. For the normal apt-get scenario, EasyInstall isn't involved, with
> the possible exception of applications like Trac installing plugins into
> their private plugins directories.
It sounds like EasyInstall **is** the package management layer I was
suggesting should be stripped when making a deb.
> > I know that package management uses
> >meta-data, but if it was implemented as one wrapped around the other,
> >you could "peel the package management layer off", leaving the metadata
> >management there, and you could produce clean deb's using only Debian
> >package management, but with the egg meta-data management still in
> >place.
>
> There's nothing to peel off, unless you believe that it's wrong to have
> runtime integrity checking. That's all the egg runtime does, unless an
[...]
I think runtime integrity checking is an unnecessary overhead when you
have decent install-time integrity checking. However, I can see how this
is useful for detecting and using optional dependencies...
> Vincenzo's idea about having easy_install be able to wrap apt-get is
> interesting, in that it would allow apps that want plugin installation to
> satisfy dependencies via system packages that *aren't* already installed,
In some ways I'd feel mildly disturbed by this. I'd tend to think of
apt-get and easy_install as seperate tools; one for managing Debian
packages, and the other for installing non-debian packaged egg's
in /usr/local.
> but in practice I think such applications are going to be restricted to
> local or specific-user installation by the very nature of their intended
> uses, so being able to have easy_install get automatically hooked to
> apt-get doesn't seem necessary to me. In the Debian world, easy_install
agreed.
> should probably only be used for user-private and/or system-local
> non-Debian stuff, including apps' private plugins. (And if you did want
> easy_install to be able to use apt-get to satisfy dependencies, it probably
> means you should just be using something like easy_deb instead, to build
> debs of the stuff you want.)
dunno how useful that is... In some ways I'd prefer a /usr/local non-deb
install than a custom-built deb.
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: