[Python-Dev] how to easily consume just the parts of eggs that are good for you
apt.shansen at gmail.com
Thu Apr 10 09:12:43 CEST 2008
> > > 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.
For people who are using a Red Had derivative, or a Debian derivative, or ..
whatever .. the package manager isn't something they go out of their way to
add and then have to struggle with. It's simply *how* their world works. By
a large measure, everything they want is there, managed by their package
For those users, I understand well that they don't want some Python package
management system to be a second system that they have to deal with.
But I'm sorry: the world is bigger then Linux and such things.
I'm a mac user, who has had extensive experience in Linux; but on the mac?
Fink and MacPorts added on top of MacOSX is not even remotely comparable to
using an operating system which has a standard package manager that is a
part of every users daily life. My operating system is Unixy, and comes
pre-installed with a number of things, including Python, wxWidgets, sqlite--
many things that make the programs I make for my customers easy to use.
But for those products that are *not* available standard, where are my mac
customers left? Their options are to install something like Fink, or
MacPorts... and then we come into issues of it wanting to install its *own*
version of python, or its *own* version of these third party things, on top
of what's already there? The alternative is that users have to install,
manually, these third-party requirements themselves.
I've found that it is in general far easier for me to just download and
install stuff manually then to rely on these "Add-on" package managers. At
least if I'm thinking of providing as minimally and least intrusive as
possible experience for my users to install my product.
Power users, especially those familiar with the Linux world, may relish in
the existence of MacPorts and Fink... Regular people, even IT managers of
companies I have to deal with-- will not.
I love easy_install/setuptools because it lets me get my *Python*
applications and products out to people, regardless of OS, in a way that
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 -- 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." Or even, "Screw
the people who aren't power users and are just not going to be able to go
through the effort of adding *on* a non-standard package management system
to their operating system."
There's a whole wide world out there that simply does *not* have a
"package management"(*) system.
Python is beautiful, making Python programs is blissful. I'd be far, far
more concerned with making it easy to distribute Python-based programs to
*any* operating system then I would be concerned with partially redoing what
a *minority* of systems out there have done to make package management (with
dependencies and all) easy for its users.
Python is a cross-platform development environment. Let's not forget that
most people just... don't have Linux... and don't have the equally blissful
world of apt or rpm available to them natively.
Its very cool to *integrate* -- to make a way for those RPM and
DEB distributors to deliver an app in their own way that will satisfy their
needs. But what about the people *without* that native capability? Having a
Python-only distribution/management system like easy_install is a *huge*
boon to getting real products to real people.
I think PJE's idea here is very good. Just include certain files and such in
the RPM/DEB that will satisfy the "python-package-management" system. For
RPM/DEB users and their OS's database of packages, its irrelevant largely--
they'll still keep using their own system. But if a product needs something
without a .deb or .rpm, or if someone's on an operating system without a
native system-- they can still gather everything they need.
My 2 cents.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev