Re: [Fwd: Re: Bug#375751: sqlobject: should use the parse method when using pkg_resources.Requirement]
Hi, On Mon, 03 Jul 2006, Gustavo Noronha Silva wrote: Hello, I'd like to request that kobold be added to the python-modules group on Alioth. I'll have sqlobject integrated to the svn repository tonight. He has been added. He will have commit rights tomorrow. 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: [HELP] new policy with a compiled python program and generic python plugin module
Le mardi 04 juillet 2006 à 09:25 +0200, Vincent Danjean a écrit : What would be the interest for an application to be present (compiled) several times on the same system ? This is the whole point of the new policy. It allows for several python versions to be installed at once. By the way, I prepared an update to the new python policy for my 3 python packages. You can look at them here : http://dept-info.labri.fr/~danjean/deb.html#commit-tool This one doesn't look good. You are explicitly hardcoding python2.3 which is exactly the wrong thing to do if you want smooth upgrades. Also, you have left some autogenerated files as postinst and prerm. http://dept-info.labri.fr/~danjean/deb.html#mercurial I don't understand why you are hardcoding python2.4 in the scripts. Do they not work with python2.3 ? You are also making complicated things like hand-made symbolic links in the python-support directories while dh_pysupport should handle them automatically. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: [HELP] new policy with a compiled python program and generic python plugin module
Josselin Mouette wrote: Le mardi 04 juillet 2006 à 09:25 +0200, Vincent Danjean a écrit : What would be the interest for an application to be present (compiled) several times on the same system ? This is the whole point of the new policy. It allows for several python versions to be installed at once. For a module, yes, but for an application ? By the way, I prepared an update to the new python policy for my 3 python packages. You can look at them here : http://dept-info.labri.fr/~danjean/deb.html#commit-tool This one doesn't look good. You are explicitly hardcoding python2.3 which is exactly the wrong thing to do if you want smooth upgrades. I hardcode python2.3 (and depend on it) so that my package still work when the python package will provide another default python interpreter. Note that it is not python2.3 that I hardcode when building, but pyversion -d. So that, when a new default python version will be uploaded, a simple binary rebuild of my package will make it working with the new python interpreter. And my package will not be broken in the time between the upload of the new python package and the binary rebuild of my package. Note: It that case, the python program includes binary blobs so it only works with the same python interpreter used at built time. This is why using #!/usr/bin/env python would lead to breakage when switching the default python version. Also, you have left some autogenerated files as postinst and prerm. Oups, I will remove them. Thanks. http://dept-info.labri.fr/~danjean/deb.html#mercurial I don't understand why you are hardcoding python2.4 in the scripts. Do they not work with python2.3 ? I use cdbs which calls pythonX.Y setup.py build in turn for each supported python versions. I saw a previous thread on this ML telling that cdbs should end with a build with python (and not pythonX.Y). My (source) script has #!/usr/bin/env python. The substitution is not from me here. You are also making complicated things like hand-made symbolic links in the python-support directories while dh_pysupport should handle them automatically. I was already doing that before the new policy (to move arch indep files from /usr/lib to /usr/share where as upstream puts all in /usr/lib) If dh_pysupport handles that automatically, I will let him doing it :-) Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
About byte compilation and cleanup when packages share a directory
Hello all, A couple of days ago I upgraded some of my python packages to follow the new policy and I've found that three of them are buggy, but I want some advice on how to proceed. The packages in question are ``childsplay``, ``childsplay-plugins`` and ``childsplay-plugins-lfc``. The fist thing I've detected is that I'm installing everything on ``/usr/share/childsplay``, but probably the right place is ``/usr/share/games/childsplay``. That is easy to fix, but before changing that I want to fix the other annoying bug, only present on ``childsplay-plugins`` and ``childsplay-plugins-lfc``. The problem comes from the use of dh_pysupport, on both packages I'm including a call like: dh_pysupport /usr/share/childsplay on debian/rules, this call can be replaced by one that only compiles the files inside the ``lib`` subdirectory, as the plugins are installed there. The dh_pysupport call will be now: dh_pysupport /usr/share/childsplay/lib or: dh_pysupport /usr/share/games/childsplay/lib if I move the private modules directory. The bug I've detected is related to the way the byte compiled files are handled; when ``childsplay`` is installed all the ``.py`` files under the ``childsplay`` modules dir are generated (including the default plugins included on ``lib``) and later, when ``childsplay-plugins`` or ``childsplay-plugins-lfc`` are installed, the same files plus the new ones are recompiled again (at least the ones inside of ``lib``, if I fix the ``dh_pysupport`` call). That is no real problem, as the double recompilation has no real effect on the system and the result is the same, the problem comes when you remove one of the plugin packages, for example the ``childsplay-plugins-lfc`` one, on that case ``dh_pysupport`` removes all the ``.pyc`` files on the ``lib`` subdirectory, that is, it removes all the byte-compiled files from ``childsplay`` and ``childsplay-plugins`` that are there. Now my questions: - How should I handle that case? - Is anybody else using a plugin system that leaves ``.py`` files inside a module directory already handled by python-support? - Should I file a bug report against python-support to implement a way to handle individual python files instead of full directories? - Does python-central solve this kind of problem? Thanks in advance for your comments. Geetings, Sergio. -- Sergio Talens-Oliag [EMAIL PROTECTED] http://people.debian.org/~sto/ Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69 signature.asc Description: Digital signature
Re: About byte compilation and cleanup when packages share a directory
Le mardi 04 juillet 2006 à 11:38 +0200, Sergio Talens-Oliag a écrit : That is no real problem, as the double recompilation has no real effect on the system and the result is the same, the problem comes when you remove one of the plugin packages, for example the ``childsplay-plugins-lfc`` one, on that case ``dh_pysupport`` removes all the ``.pyc`` files on the ``lib`` subdirectory, that is, it removes all the byte-compiled files from ``childsplay`` and ``childsplay-plugins`` that are there. Yes, this is a known problem. - How should I handle that case? As is, this is harmless, so I think you can just wait for the fix in python-support. - Is anybody else using a plugin system that leaves ``.py`` files inside a module directory already handled by python-support? - Should I file a bug report against python-support to implement a way to handle individual python files instead of full directories? Yes, this will be a way to track this problem. - Does python-central solve this kind of problem? Python-central relies on package listings, so it wouldn't have such problems. However it doesn't handle private modules at all. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
