> > > > 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 management system. 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 just *works*. 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. Anyways. My 2 cents. --Stephen
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
