[EMAIL PROTECTED] wrote: > Another point that I'd like to make is that I believe we should avoid > reimplementing > RPM, DEB, fink, whatever. Or at least we should not ignore them. We can > produce > meta-data that supports those packaging formats. Thus a user has the > opportunity to > install Python software using the existing package management mechanisms > installed > in their system, rather than something new and independent just for Python. > The > latest PEP I've proposed adds some meta-data that makes the DEB-alike > packagers more > happy, and should also help out RPM packagers. > > Distutils already does a fairly good job of handling the actual installation > of > Python software -- it compiles things, can install data files, with a little > extra > effort other stuff can be done too. It generates RPMs, DEBs, Windows > Installers. > There's a desire from the Ubuntu packagers to add a doc_files option to the > setup() > args, but that's for another discussion. > > Anyway, I'm rambling. My point is clear though: I believe we should avoid > developing > Yet Another Packaging System just for the sake of it. And certainly we should > play > well with others where possible.
OTOH, there is a place for distutils installs even in the presence of native packaging. Because Python doesn't have versioned imports, in many situations (at least the kind of stuff I do) a system-wide installation isn't appropriate. And most native packagers don't do well at localized installations. > I guess we need to ask what it is that our database of installed Python > modules will > achieve that the existing packaging systems don't. Of course, I don't know what a database would achieve exactly in this case either, except perhaps in the presence of versioned imports. Which I guess Eggs provide, in a way. But then Eggs mix it up too, since wouldn't be "installed" either, they just get put in the right place, and so there's no chance for a database to recognize them. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Catalog-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
