Re: Deprecating /usr/lib/site-python in python policy
On Mon, 12 Jun 2006, Alexandre Fayolle wrote: > > Since this directory is in sys.path of all python versions, if we > > byte-compile those in-place for the current version, then the modules > > won't work with other python versions. > > This just not true. Python is smart enough not to use the .pyc if the > version used to produce it is not the one which is used. The problem > only exists for python extensions, but pure python modules have no > problem with this. /usr/lib/site-python is on the sys.path of all python versions so we must make sure to provide the best (ie .py with working .pyc) for all python versions. We can't do that within /usr/lib/site-python so we must do it outside. python-support and python-central provides convenient support for that. Any package using /usr/lib/site-python shoud be changed to use one of those ... or if the modules shouldn't be public, then it should use a private directory that the application manually adds to the sys.path. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New Python policy
I have updated the Python policy document based on the discussions on the list. An updated DebianDoc (and HTML and text files) can be found at http://people.debian.org/~piman/python-policy/. It: 0) Removes a lot of cruft/debate from the document itself 1) Explains X*-Python-Version 2) Explains that we don't want tight dependencies 3) Deprecates /usr/lib/site-python 4) Outlines using python-support/central with debhelper 5) Tries to cover more on private modules It does not: 1) Cover CDBS, since I don't know how to use it properly 2) Give examples for Python packages without using debhelper; I suspect those are now almost impossible to make sanely. Probably: 1) The "Upgrade Procedure" section needs work (from RMs) 2) I have some details wrong 3) My explanations could be clearer (but I feel it's an improvement over the old structure) -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: New Python policy
Joe Wreschnig ([EMAIL PROTECTED]): > I have updated the Python policy document based on the discussions on > the list. An updated DebianDoc (and HTML and text files) can be found at > http://people.debian.org/~piman/python-policy/. great work! [...] > It does not: > 1) Cover CDBS, since I don't know how to use it properly > 2) Give examples for Python packages without using debhelper; > I suspect those are now almost impossible to make sanely. What about an Egg support? I think it's worth mentioning in policy I'm talking about: * --single-version-externally-managed parameter passed to `setup.py install` or DEB_PYTHON_INSTALL_ARGS_ALL (CDBS) * Egg's dirname's issue (python's/module's version in dirname) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpQfkJw9XNz9.pgp Description: PGP signature
Re: Bug#370833: New dh_python proposal
On Mon, 12 Jun 2006, Raphael Hertzog wrote: > I would love to have this fixed by today's dinstall. That's why I > prepared the attached NMU, please just send an OK and I'll upload it (of > course, feel free to do it yourself in a maintainer upload). > > Without any answer from you, I might upload it right before dinstall > (depending on the opinion of other involved people). Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC today (in about 9.5 hours). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Piotr Ozarowski writes: > What about an Egg support? I think it's worth mentioning in policy > > I'm talking about: > * --single-version-externally-managed parameter passed to > `setup.py install` or DEB_PYTHON_INSTALL_ARGS_ALL (CDBS) > * Egg's dirname's issue (python's/module's version in dirname) the python version information should be dropped, the module's version can be dropped. Checked with Phil Eby. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Hi On Mon, 12 Jun 2006 02:29:51 -0500 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > I have updated the Python policy document based on the discussions on > the list. An updated DebianDoc (and HTML and text files) can be found at > http://people.debian.org/~piman/python-policy/. How about adding example for building compiled extensions? Otherwise there will be used many ways to produce binaries for all supported python versions. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: New Python policy
> How about adding example for building compiled extensions? Otherwise > there will be used many ways to produce binaries for all supported > python versions. - Packaging examples - CDBS (not yet available) - python-central (http://python-modules.alioth.debian.org/python-central_howto.txt) - python-support (http://wiki.debian.org/DebianPythonFAQ) If a package has just extensions, then you don't need python-support or python-central at all. Just put all extensions for each supported python version into the same python-foo package. We do not explicitely disallow having copies of the same .py files in /usr/lib/pythonX.Y, so that can be done as well (example is python-newt which comes with one extension and one module). Extensions and modules in packages (the python sense, a directory with an __init__.py) must end up in the same directory. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#370833: New dh_python proposal
On Mon, 12 Jun 2006, Raphael Hertzog wrote: > On Mon, 12 Jun 2006, Raphael Hertzog wrote: > > I would love to have this fixed by today's dinstall. That's why I > > prepared the attached NMU, please just send an OK and I'll upload it (of > > course, feel free to do it yourself in a maintainer upload). > > > > Without any answer from you, I might upload it right before dinstall > > (depending on the opinion of other involved people). > > Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC > today (in about 9.5 hours). And for extra-care, here's the package for testing: http://people.debian.org/~hertzog/python/ http://people.debian.org/~hertzog/python/debhelper_5.0.37.1_all.deb Please test and report me ASAP any problem with it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Hi, On Mon, 12 Jun 2006, Michal Čihař wrote: > On Mon, 12 Jun 2006 02:29:51 -0500 > Joe Wreschnig <[EMAIL PROTECTED]> wrote: > > > I have updated the Python policy document based on the discussions on > > the list. An updated DebianDoc (and HTML and text files) can be found at > > http://people.debian.org/~piman/python-policy/. > > How about adding example for building compiled extensions? Otherwise > there will be used many ways to produce binaries for all supported > python versions. There will be example packages soon we hope. In the mean time, I can tell you that you will have to Build-Depends on "python (>= 2.3.5-6), python-all-dev" and that you should use `pyversions -r debian/control` to find out the list of python versions that you must use to build the package with, then your job in the rules file is to do something like that: for python in $(PYVERS); do \ $$python setup.py ...; \ done Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#370833: New dh_python proposal
Coin, Raphael Hertzog <[EMAIL PROTECTED]> writes: > Without any answer from you, I might upload it right before dinstall > (depending on the opinion of other involved people). This is perfectly reasonnable. -- Marc Dequènes (Duck) pgpU3t0AM8OF7.pgp Description: PGP signature
Re: New Python policy
Hi no need to CC me... On Mon, 12 Jun 2006 12:34:18 +0200 Matthias Klose <[EMAIL PROTECTED]> wrote: > - Packaging examples >- CDBS (not yet available) >- python-central > (http://python-modules.alioth.debian.org/python-central_howto.txt) >- python-support (http://wiki.debian.org/DebianPythonFAQ) > > If a package has just extensions, then you don't need python-support > or python-central at all. Just put all extensions for each supported > python version into the same python-foo package. We do not > explicitely disallow having copies of the same .py files in > /usr/lib/pythonX.Y, so that can be done as well (example is > python-newt which comes with one extension and one module). I understand this, I just want that policy mentions what is suggested way to get all supported python versions (and thus what pythonX.Y to call setup.py with). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: New Python policy
Hi On Mon, 12 Jun 2006 13:18:53 +0200 Raphael Hertzog <[EMAIL PROTECTED]> wrote: > In the mean time, I can tell you that you will have to Build-Depends on > "python (>= 2.3.5-6), python-all-dev" and that you should use `pyversions > -r debian/control` to find out the list of python versions that you must > use to build the package with, [...] This is exactly information I miss there right now. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: New Python policy
Coin, Matthias Klose <[EMAIL PROTECTED]> writes: >> How about adding example for building compiled extensions? Otherwise >> there will be used many ways to produce binaries for all supported >> python versions. > > - Packaging examples >- CDBS (not yet available) A packaging example can be found here : http://perso.duckcorp.org/duck/soya-new-policy/ What needs to be done: - use the splited dh_* script intead of the former dh_python updated script (will be done today) - use the script in python-dev for build version calculation instead of the internal code (when a test package is available) - move the class into cdbs itself (i plan to contact Peter today) - test it widely This class is aware of builddeps generation, so you can use the feature manually to avoid missing stuff. dh_* would handle tool-specific dependencies. The CDBS documentation would be done soon (in the original documentation not in the package, for those aware of the fork issue). Btw, unfortunately apt is absolutely unable to handle versioned dependencies when those have switched from real dependencies to provides, then you may have to fix packages depending on your libraries. In my cdbs packaging example i will have to fix balazar (but not slune). -- Marc Dequènes (Duck) pgpSyfweyvQUZ.pgp Description: PGP signature
Re: Deprecating /usr/lib/site-python in python policy
On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote: > /usr/lib/site-python is on the sys.path of all python versions so we must > make sure to provide the best (ie .py with working .pyc) for all python > versions. Why "must"? Has this for some reason become a problem just recently or has this always been a problem? I do not think missing or invalid .pyc's there could cause noticable performance problems (especially since it is at the end of the search path or at least near it) and certainly the modules are importable from multiple python versions already. As a user I am greatful for all the people making an effort to improve Debian Python, but I am beginning to worry if you people are taking too many steps at once this close to the freeze. signature.asc Description: Digital signature
Re: Deprecating /usr/lib/site-python in python policy
On Mon, 12 Jun 2006, Juha-Matti Tapio wrote: > On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote: > > /usr/lib/site-python is on the sys.path of all python versions so we must > > make sure to provide the best (ie .py with working .pyc) for all python > > versions. > > Why "must"? Well "should". > Has this for some reason become a problem just recently or has this always > been a problem? I do not think missing or invalid .pyc's there could cause It's not a major problem, we won't be pushing hard for it but it's good to update the policy accordingly however. We'll concentrate on fixing the modules first. The application won't stop working whereas modules could. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Deprecating /usr/lib/site-python in python policy
On Mon, 2006-06-12 at 17:08 +0300, Juha-Matti Tapio wrote: > On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote: > > /usr/lib/site-python is on the sys.path of all python versions so we must > > make sure to provide the best (ie .py with working .pyc) for all python > > versions. > > Why "must"? > > Has this for some reason become a problem just recently or has this always > been a problem? I do not think missing or invalid .pyc's there could cause > noticable performance problems (especially since it is at the end of the > search path or at least near it) and certainly the modules are importable > from multiple python versions already. > > As a user I am greatful for all the people making an effort to improve > Debian Python, but I am beginning to worry if you people are taking too many > steps at once this close to the freeze. Only a dozen or so packages bother with /usr/lib/site-python, and almost all of them are buggy for placing unstable APIs in a public module directory anyway. Note that it's *not* being removed from sys.path (yet), it's just being deprecated. We deprecated /usr/doc with far more than a dozen packages still using it. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Debhelper support should be ready tomorrow
On Mon, 12 Jun 2006, Raphael Hertzog wrote: > On Mon, 12 Jun 2006, Raphael Hertzog wrote: > > I would love to have this fixed by today's dinstall. That's why I > > prepared the attached NMU, please just send an OK and I'll upload it (of > > course, feel free to do it yourself in a maintainer upload). > > > > Without any answer from you, I might upload it right before dinstall > > (depending on the opinion of other involved people). > > Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC > today (in about 9.5 hours). Debhelper uploaded. We also had a python-central upload (fixing dh_pycentral) and a python-support (adding dh_pysupport). So hopefully we should be able to really start updating modules to the new policy tomorrow. Build-Depends will have to require: - python (>= 2.3.5-7) (for pyversions script) - debhelper (>= 5.0.37.1) (first dh_python for the new policy) - python-central (>= 0.4.10) (fixed dh_pycentral to work with new dh_pyhton) - python-support (>= 0.2.3) (first version with dh_pysupport) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper support should be ready tomorrow
On Mon, Jun 12, 2006 at 09:06:43PM +0200, Raphael Hertzog wrote: > On Mon, 12 Jun 2006, Raphael Hertzog wrote: > > On Mon, 12 Jun 2006, Raphael Hertzog wrote: > > > I would love to have this fixed by today's dinstall. That's why I > > > prepared the attached NMU, please just send an OK and I'll upload it (of > > > course, feel free to do it yourself in a maintainer upload). > > > Without any answer from you, I might upload it right before dinstall > > > (depending on the opinion of other involved people). > > Just to avoid confusion, this would mean uploading between 18:00 and 19:00 > > UTC > > today (in about 9.5 hours). > Debhelper uploaded. We also had a python-central upload (fixing > dh_pycentral) and a python-support (adding dh_pysupport). So hopefully we > should be able to really start updating modules to the new policy tomorrow. > Build-Depends will have to require: > - python (>= 2.3.5-7) (for pyversions script) Are packages expected to call pyversions directly, or is this something that should be a versioned dep from one of the other build-dependencies? Hmm, I guess it's called by dh_python, and debhelper doesn't depend on python at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper support should be ready tomorrow
On Mon, 2006-06-12 at 12:25 -0700, Steve Langasek wrote: > On Mon, Jun 12, 2006 at 09:06:43PM +0200, Raphael Hertzog wrote: > > On Mon, 12 Jun 2006, Raphael Hertzog wrote: > > > On Mon, 12 Jun 2006, Raphael Hertzog wrote: > > > > I would love to have this fixed by today's dinstall. That's why I > > > > prepared the attached NMU, please just send an OK and I'll upload it (of > > > > course, feel free to do it yourself in a maintainer upload). > > > > > Without any answer from you, I might upload it right before dinstall > > > > (depending on the opinion of other involved people). > > > > Just to avoid confusion, this would mean uploading between 18:00 and > > > 19:00 UTC > > > today (in about 9.5 hours). > > > Debhelper uploaded. We also had a python-central upload (fixing > > dh_pycentral) and a python-support (adding dh_pysupport). So hopefully we > > should be able to really start updating modules to the new policy tomorrow. > > > Build-Depends will have to require: > > - python (>= 2.3.5-7) (for pyversions script) Okay, I've updated the policy document to use that version in the Build Dependencies section. > Are packages expected to call pyversions directly, or is this something that > should be a versioned dep from one of the other build-dependencies? Some packages will call pyversions themselves to get the available list of Python versions, and run each one on setup.py (see [EMAIL PROTECTED] for an example). Pure Python modules using python-support won't need to. > Hmm, I guess it's called by dh_python, and debhelper doesn't depend on > python at all. Yes, this is already the cause of many FTBFS bugs in Python packages when developers don't test in pbuilder. I've added a note to the policy to this effect as well. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Debhelper support should be ready tomorrow
On Mon, 12 Jun 2006, Joe Wreschnig wrote: > > > - python (>= 2.3.5-7) (for pyversions script) > > Okay, I've updated the policy document to use that version in the Build > Dependencies section. Which is only really needed for extensions. Modules don't need more than an unversioned dependency on python / python-dev. Extensions will also need a build-dep on python-all-dev. > > Are packages expected to call pyversions directly, or is this something that > > should be a versioned dep from one of the other build-dependencies? > > Some packages will call pyversions themselves to get the available list > of Python versions, and run each one on setup.py (see > [EMAIL PROTECTED] for an example). Pure Python modules > using python-support won't need to. ... using python-support or python-central BTW. > > Hmm, I guess it's called by dh_python, and debhelper doesn't depend on > > python at all. No, pyversions is not (yet) used by dh_python. I don't need to know which versions I'm building but which version I have built... If we want dh_python to fail when the versions built do not match what has been announced in XS-Python-Version, then I might start using it (but I have perl code to do the same since it was in my first dh_python). -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper support should be ready tomorrow
Raphael Hertzog writes: > On Mon, 12 Jun 2006, Joe Wreschnig wrote: > > > > - python (>= 2.3.5-7) (for pyversions script) > > > > Okay, I've updated the policy document to use that version in the Build > > Dependencies section. > > Which is only really needed for extensions. Modules don't need more than > an unversioned dependency on python / python-dev. > > Extensions will also need a build-dep on python-all-dev. except if you build an extension for just the default version. > > > Hmm, I guess it's called by dh_python, and debhelper doesn't depend on > > > python at all. > > No, pyversions is not (yet) used by dh_python. I don't need to know which > versions I'm building but which version I have built... > > If we want dh_python to fail when the versions built do not match what has > been announced in XS-Python-Version, then I might start using it (but I > have perl code to do the same since it was in my first dh_python). we should detect that. the resulting package will not be usable? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What to do when a source package has Python components in a subdir?
Since Python policy is being revamped just now I thought I'd bring up a complicated situation that I ran across recently (in packages that are currently just for private use, but I might try to get them into Debian eventually). Consider a source package that builds a shared library, Python bindings for that library (consisting of both "extensions" and "modules"), and programs for /usr/bin that are written in Python and use the library bindings. Upstream distributes this as one big tarball with a top-level autoconf-based configure script and Makefile. The Python bindings are in a subdirectory; Make recurses into that directory and invokes setup.py there. Upstream makes no provision for building the bindings against multiple versions of Python; however, they work fine with all versions I've tried (2.3 and 2.4). Policy questions: * What is the appropriate set of binary packages for this scenario, and what goes in each? * What should the /usr/bin programs have on their #! line? (I assume /usr/bin/python, i.e. the default version, but explicitness would be good.) Packaging practices question: * What is the best way to code debian/rules for this scenario? Hack up the upstream Makefiles to run setup.py repeatedly, or have debian/rules reach in there and invoke it itself, or what? Thanks, zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do when a source package has Python components in a subdir?
Zack Weinberg writes: > Since Python policy is being revamped just now I thought I'd bring up > a complicated situation that I ran across recently (in packages that > are currently just for private use, but I might try to get them into > Debian eventually). > > Consider a source package that builds a shared library, Python > bindings for that library (consisting of both "extensions" and > "modules"), and programs for /usr/bin that are written in Python and > use the library bindings. Upstream distributes this as one big > tarball with a top-level autoconf-based configure script and Makefile. I assume these bindings are for public usage. > The Python bindings are in a subdirectory; Make recurses into that > directory and invokes setup.py there. Upstream makes no provision for > building the bindings against multiple versions of Python; however, > they work fine with all versions I've tried (2.3 and 2.4). > > Policy questions: > > * What is the appropriate set of binary packages for this scenario, > and what goes in each? - the minimum would be one binary package - a python-foo package can be split out (if there is a large chunk of modules, it could further be split out into a python-foo and python-foo-bin package. > * What should the /usr/bin programs have on their #! line? (I assume > /usr/bin/python, i.e. the default version, but explicitness would be > good.) yes, we should mention that. I'm not sure, how /usr/bin programs should be handled which are installed versioned (foo-py23-bin, foo-py24-bin) and use the versioned interpreter explicitely. Just remove them, and keep foo-bin, or keep them all, but do not explicitely depend on the versioned python packages. > Packaging practices question: > > * What is the best way to code debian/rules for this scenario? Hack > up the upstream Makefiles to run setup.py repeatedly, or have > debian/rules reach in there and invoke it itself, or what? depends on the packaging system, but that decision is up to the package maintainer. I looked once at subversion and just did build the whole stuff twice. If you have the possibility to just build the python stuff, then maybe build the package for the default version completley, and then for the other versions EXTRAVERS := $(filter-out $(shell pyversions -d), $(shell pyversions -r)) build: $(EXTRAVERS:%=build-python%) build-python%: python$* setup.py build install: build $(EXTRAVERS:%=install-python%) install-python%: python$* setup.py install --no-compile \ --root $(CURDIR)/debian/python-foo Hacking the upstream Makefiles should be done independently from the currently supported python versions. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Joe Wreschnig writes: > I have updated the Python policy document based on the discussions on > the list. An updated DebianDoc (and HTML and text files) can be found at > http://people.debian.org/~piman/python-policy/. > > It: > 0) Removes a lot of cruft/debate from the document itself > 1) Explains X*-Python-Version > 2) Explains that we don't want tight dependencies > 3) Deprecates /usr/lib/site-python > 4) Outlines using python-support/central with debhelper > 5) Tries to cover more on private modules > > It does not: > 1) Cover CDBS, since I don't know how to use it properly > 2) Give examples for Python packages without using debhelper; > I suspect those are now almost impossible to make sanely. Some additions: - mention /usr/share/python/debian_defaults - add paragraph about python packages - describe the XB-Python-Version field - add section about provides - extend paragraph about byte compilation - remove the paragraph about distutils - enhance the section about support tools Matthias pypol.diff Description: Binary data
Instructions to update a package for the new python policy
Hi, I've prepared this: http://wiki.debian.org/DebianPython/NewPolicy Feel free to enhance. I also converted python-pam as an example (std debhelper package): http://people.debian.org/~hertzog/python/examples/ I'll gladly put other examples packages at the same place. Just send them to me. Now it's time to ask all maintainers to update their packages. Someone should prepare several list of source packages: - python extensions - python modules only - python apps Then we need to fill bugs, and usertag them "policy-ext", "policy-mod" and "policy-apps" with identity "debian-python@lists.debian.org" to be able to follow the progress here: http://bugs.debian.org/usertag:debian-python@lists.debian.org Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
On Tue, 2006-06-13 at 01:14 +0200, Matthias Klose wrote: > Joe Wreschnig writes: > > I have updated the Python policy document based on the discussions on > > the list. An updated DebianDoc (and HTML and text files) can be found at > > http://people.debian.org/~piman/python-policy/. > > > > It: > > 0) Removes a lot of cruft/debate from the document itself > > 1) Explains X*-Python-Version > > 2) Explains that we don't want tight dependencies > > 3) Deprecates /usr/lib/site-python > > 4) Outlines using python-support/central with debhelper > > 5) Tries to cover more on private modules > > > > It does not: > > 1) Cover CDBS, since I don't know how to use it properly > > 2) Give examples for Python packages without using debhelper; > > I suspect those are now almost impossible to make sanely. > > Some additions: > > - mention /usr/share/python/debian_defaults > - add paragraph about python packages > - describe the XB-Python-Version field > - add section about provides > - extend paragraph about byte compilation > - remove the paragraph about distutils > - enhance the section about support tools Merged and updated the site. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Instructions to update a package for the new python policy
Coin, Raphael Hertzog <[EMAIL PROTECTED]> writes: > Now it's time to ask all maintainers to update their packages. Someone > should prepare several list of source packages: > - python extensions > - python modules only > - python apps Fact is python-support is not yet ready for extensions, and CDBS class not yet integrated into the cdbs package. I talked to Joss about it today (which is yesterday for humans), and we are near a solution, this should be solved soon. I made the simplifications and changes needed in the CDBS class, but still a bug remains. I hope this would be solved tomorrow. Btw, you forgot to enforce python-support à least >= 0.2, or even 0.2.2 in the generated Depends (suggested on IRC). -- Marc Dequènes (Duck) pgpDNUyXnhcaz.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, > With the upcoming releases of the last packages which > didn't support 2.4 yet (Plone on the Zope application server) we may > be able to drop support for 2.3 in sid and etch as well. For reference, decompyle still needs python2.3. There are two issues: 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). Issue #2 is not really relevant to dropping python2.3, since keeping python2.3 around is not going to help the fact that people will be wanting to decompile bytecode for the new default python2.4. Issue #1 is a problem however, so if there are plans to drop 2.3 for etch, I'd be very happy for a rough timeframe so I know when this all needs to be dealt with. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New python distutils class
Coin, As you may have heard, Python packaging is moving fast these days. We plan the move the current Python version to 2.4 and in the same time are drafting a new policy and creating new tools to greatly improve the current situation. All this leads to the need for a newer class, which will at the end replace the current one completly. The current status is : the class was updated today to reflect the latest changes in the debhelper dh_python script and tool-specific helpers. Remains a bug i'll try to fix tomorrow, and i need to test it with another package, just to be sure nothing is left over. Then, i'd like your support to integrate this class as soon as possible, when it is considered finished, to allow moving to the new policy approximately at the same time we move to 2.4, to avoid making the transition longer than necessary. I of course would appreciate much if you could have a look at it before and give some advice. You can find the current class here : http://perso.duckcorp.org/duck/soya-new-policy/ For the documentation point of view, as our documentation are forked, i'll write what is necessary in the original one and, by rights given by the licence, you may borrow what you need to update yours. -- Marc Dequènes (Duck) pgp0Bg2R3jcUC.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Coin, Ben Burton <[EMAIL PROTECTED]> writes: > For reference, decompyle still needs python2.3. There are two issues: > > 1. It won't build under python2.4. I have fixes for this that I haven't >uploaded (and that need some more testing and tidying up). You may still ask for help. > 2. It won't decompile python2.4 bytecode. This will be somewhat harder >to fix (and I haven't done it yet). If it is not able to decompile recent python version, then it is a kind of useless one. Python 2.4 is out since a while, what are upstream plans for their software ? -- Marc Dequènes (Duck) pgpASsE9n5U8g.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, > > 1. It won't build under python2.4. I have fixes for this that I haven't > >uploaded (and that need some more testing and tidying up). > > You may still ask for help. This will be easy enough to have ready by the time 2.3 is removed, which I'm assuming is not happening tomorrow. Where I'd love the help is with the python2.4 decompilation (see below). > > 2. It won't decompile python2.4 bytecode. This will be somewhat harder > >to fix (and I haven't done it yet). > > If it is not able to decompile recent python version, then it is a kind > of useless one. Well, it's certainly useful at the moment since python2.3 is the default, and I claim it's still useful even after python2.3 is dropped -- just because debian changes the default python doesn't mean all your old bytecode disappears. One of the more important uses of this software is for repairing things in an emergency (e.g., rm *.py, oops), which is why I want to keep it around. > Python 2.4 is out since a while, what are upstream plans for their software ? Upstream went commercial back in the 2.2 days. The debian packages forked and essentially became the de-facto upstream source when 2.3 decompilation was introduced, and it's still that way now. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python distutils class
On Tue, 13 Jun 2006, Marc Dequènes wrote:
> Coin,
[...]
> You can find the current class here :
> http://perso.duckcorp.org/duck/soya-new-policy/
Some things to fix:
> cdbs_python_build_versions := $(patsubst python%, %, $(shell pyversions -r
> debian/control | grep -E "^python[0-9.]+( python[0-9.]+)*$$"))
You shouldn't be removing "python" here because "pyversions" may return "python"
(without any version) if XS-Python-Version is "current".
This means that:
> common-build-arch common-build-indep:: $(addprefix python-build-stamp-,
> $(cdbs_python_build_versions))
> python-build-stamp-%:
> cd $(DEB_SRCDIR) && python$* $(DEB_PYTHON_SETUP_CMD) build
> $(DEB_PYTHON_BUILD_ARGS)
> touch $@
This needs to be changed (use "$*" instead of "python$*") and likewise for
"python-install-%:"
and "python-clean-%".
Then:
> binary-install/$(DEB_PYTHON_MODULE_PACKAGE) :: binary-install/%:
> ifeq (, $(cdbs_python_use_python_central))
> dh_pysupport
> else
> dh_pycentral
> endif
> dh_python -p$(DEB_PYTHON_MODULE_PACKAGE)
> $(DEB_PYTHON_PRIVATE_MODULES_DIRS)
> endif
You obviously need to give the same "-p$(DEB_PYTHON_MODULE_PACKAGE)" to
dh_pycentral
and dh_python. And dh_pysupport also needs the
$(DEB_PYTHON_PRIVATE_MODULES_DIRS).
Concerning:
> # TODO: detect if $(DEB_PYTHON_MODULE_PACKAGE) is an archall package to build
> only for current version
Here's a bit of perl that you can use to extract the Architecture: field
of a given binary package. (Not very nice but hey)
perl -e '$/=""; $_=(grep {/^Package: python-imaging-doc$/m;} (<>))[0];
/^Architecture: (.*)$/m && print $1' debian/control
Replace python-imaging-doc by $(DEB_PYTHON_MODULE_PACKAGE) and escape
everything properly...
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python distutils class
Raphael Hertzog writes: > On Tue, 13 Jun 2006, Marc Dequènes wrote: > > Coin, > [...] > > You can find the current class here : > > http://perso.duckcorp.org/duck/soya-new-policy/ > > Some things to fix: > > cdbs_python_build_versions := $(patsubst python%, %, $(shell pyversions -r > > debian/control | grep -E "^python[0-9.]+( python[0-9.]+)*$$")) > > You shouldn't be removing "python" here because "pyversions" may return > "python" > (without any version) if XS-Python-Version is "current". pyversions -r always prints the resolved, real versions. Matthias
Re: New python distutils class
Marc Dequènes wrote: > As you may have heard, Python packaging is moving fast these days. We > plan the move the current Python version to 2.4 and in the same time > are drafting a new policy and creating new tools to greatly improve > the current situation. All this leads to the need for a newer class, > which will at the end replace the current one completly. Thank you for working on this. I haven't tested this yet at all, but I have a couple of small concerns about your proposal: - Perhaps in keeping with the style of cdbs, it would be better to have two classes python-pycentral and python-pysupport (and some python-common or python-core) behind it? This would also avoid the tacky use of -ng in the class name. :-) - DEB_PYTHON_MODULE_PACKAGE should perhaps default to the package that matches python-* in addition to the other criteria? - The appearance of the DEB_PYTHON_PRIVATE_MODULES_DIRS variable seems to be unrelated to this change. I don't doubt it might be useful, but I just want to be sure where it's coming from. At the risk of reopening a flame war, what is the point of supporting two build systems? I can understand that when you write your rules file by hand, one system or the other may be more convenient in a particular situation. But when cdbs runs things, it seems to make no difference to the users, so why should they be burdened with this choice? Btw., before this can be uploaded, it would be good if some of these build dependencies existed first, so a test case can be written. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
