On Monday 21 November 2005 05:16 pm, you wrote: > > Is Debian python policy dated or wrong? > > > > Debian moving a different direction then upstream python? > > surely our policy needs to adopt the new schema. I don't think it's > dated or wrong. there are things which we do want to prevent: > > - package more than one version of a module in the distribution, > apparently that's something that the egg format encourages. > > - an "copy all needed modules into an egg" approach. IMO this is > wrong for a distribution. If you look at more complex packages, > you'll already find that style very often. and all these packages > have to be modified to use a "system" version. > > I know that setuptools offers a possibility to install in the "old" > way (directly into site-packages), for a distribution like Debian that > looks like the preferred way. I'm not sure if you are distutils-sig, but I posted snippets from our email conversation and Ian Bickering, one of the main developers of distutils/setuptool had this to say: I do think we need to resolve these issues with Linux distributions. I'd encourage ... [Matthias] ... to join this list, and we can discuss how this stuff should work. I've attached Ian's email as well. -- Bob Tanner <tanner@real-time.com> | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288
Bob Tanner wrote: >>This isn't a "problem", it's just that the Debian policy isn't >>up-to-date. Python eggs install this way, and many packages (e.g. >>TurboGears) require the new structure. > > > Then we have a problem in the Debian world. :-( Here is a snippet of an > email I received from the Debian powers. I also believe this individual is > one of the authors of the python-policy for Debian. I've X'd the name/email > to protect the innocent. I do think we need to resolve these issues with Linux distributions. I'd encourage the X in question to join this list, and we can discuss how this stuff should work. Some of what Python Eggs do are redundant with a Debian package (though that redundancy can be used to positive effect) and some parts of Eggs offer features that don't fit into Debian packaging very well (like multiple installations of different versions of the same library, which requires versions in the package names themselves in Debian). Also, .pth file management is a bit of an issue, and is something that should be addressed by Debian policy, as it's somewhere where packages should cooperate. There are performance issues with every package having its own .pth file. > ===================== snip ================================== > >>On Monday 21 November 2005 09:09 am, XXXXXXX XXXXXX wrote: >> >>>$ dpkg -L python2.4-formencode >>>[...] >>>/usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg >>>/usr/share/doc/python2.4-formencode/copyright >>>/usr/share/doc/python2.4-formencode/changelog.Debian.gz >>> >>>??? Please don't do that in a Debian package. >> >>First question, why? >> > > Because you can't us it with a simple "use formencode". > "pydoc" doesn't work with eggs either. I think there's a good argument that Python isn't quite ready for installing zip files, in that lots of tools don't work that well with them right now. This can be addressed in code through distutils settings -- you can force all files to be unzipped globally in distutils.cfg, and perhaps Debian could hook into that (if they don't want to create a distutils.cfg file, which is reasonable as that can be useful for user configuration). >>If it break Debian policies, please point me to the appropriate >>section(s) and documents. I wasn't able to find any related to python >>module packaging. >> > > zless /usr/share/doc/python/python-policy.txt.gz > > >>Lastly that is the default installation method when using cdbs. Which I > > think > >>just delegates it to the setup.py (ie authors choice?) >> > > Probably. .egg packages might be a nice generic way to ship Python stuff > to random OS installations, but I don't think they should be used in > standard Python packages that are shipped in a Linux distribution like > Debian. > ===================== snip ================================== > > To comply, I added a zip_safe = False to the setup() of FormEncode, then > moved > > /usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg/formencode > > TO > > /usr/lib/python2.4/site-packages/formencode > > Are you saying the comply-hack- above will potentially break other python > packages (like Turbogears)? You lose metadata that TurboGears really wants to have; this isn't just dependency information, but also plugin information (which I don't think is being used in 0.7, but will be for 0.8). Python packages can't be expected to read Debian package metadata. Also more generally, I think Debian needs to play more nicely with user-installed packages, and if you rely purely on Debian metadata for detecting installed packages, you lose useful information. As of a few months ago I've moved to Ubuntu, so I don't know what the exact situation is on Debian, but after learning more about distutils I've realized that Debian has been missing functionality that would make user-installed code better adhere to Debian policy (like installing into /usr/local/lib/pythonX.Y). So I think Debian policy really needs some fixing on these matters anyway. FWIW, Ubuntu sponsored a project for making Eggs work better there: http://easy-deb.sourceforge.net/ -- it doesn't mean they'll necessarily use that work (I have no idea what their plans are, and Google Summer of Code work doesn't imply anything except interest). I'd like it to be possible to do "python setup.py bdist_deb" and get a Debian package; I think this should be very doable if we get some participation from people with Debian packaging experience. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
Attachment:
pgpOoRe0zUefu.pgp
Description: PGP signature