[Python-Dev] how to easily consume just the parts of eggs that are good for you
Stephen J. Turnbull
stephen at xemacs.org
Thu Apr 10 10:30:41 CEST 2008
Stephen Hansen writes:
> >
> > > > IMHO, the main system without a package manager is Windows.
> > >
> > > AFAICT the MacOS platform also lacks in this area.
> >
> > Actually, they both have them. Windows has Cygwin (rpm-based), while
> > for MacOS Fink (deb-based), MacPorts (FreeBSD ports-like), and
> > NetBSD's pkgsrc are all viable options if you want packaging support
> > for 3rd-party packages.
>
> Er, excuse me for cutting in but-- that's just not at all the same
> thing.
[...]
> I do think its valuable to do so in a way that will integrate with native
> package managers on those operating systems that they are a native and
> integrated part of
Why restrict it to those? That's my point. If you're going to make
it apt-compatible, you should do all the others, too, because there
are lots of people using them. Whether or not they are OS-provided.
As far as I'm concerned, asking a Python tool to integrate into any
pms is a non-starter because it really means asking for integration
into all of them.
> but to say, "Let's not re-create apt!" is a sorrowful stance. It's
> saying, "Screw Windows, because it isn't as good as what we have."
> and "Screw Mac, because its not as good as we have."
It's worse than that. One point I hoped to make is that "Let's not
recreate apt!" is a way of saying "Screw Windows and Mac and Red Hat
and Gentoo and NetBSD and FreeBSD and ...."
I think it's worth working out a standard format for documenting
dependencies so that a downstream distributor can easily create a
dependency graph (perhaps several of them, since system bootstrap,
package build-time, and package run-time may have different
requirements). And standard Python distribution media should have a
"manual mode" so that distros can decide where to put things. But
that's as far as Python itself should ever go; fitting those things
into any given pms is the downstream distro's job.
More information about the Python-Dev
mailing list