Re: Question about python policy
On Wed, 2004-02-11 at 11:28, Florent Rougon wrote: There used to be a tool called python-central [...] It probably doesn't solve the case where you need a certain version of python to run build-time test cases and such. I guess it might have been a good idea, but since it didn't catch on, perhaps it was too complicated. Anyway, I pretty much know what to do now, and if policy will ever mandate a better way then I'll convert my package to using it. -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Question about python policy
Fabian Fagerholm [EMAIL PROTECTED] wrote: It probably doesn't solve the case where you need a certain version of python to run build-time test cases and such. I guess it might have been a good idea, but since it didn't catch on, perhaps it was too complicated. Build-time tests are run, well, at build-time. Nothing prevents you from build-depending on every pythonX.Y you wish and doing every test that might please you, regardless of whether you are using python-central. Also, python-central was not complicated. For version 0.3 (0.4 was released later but I didn't install it): % wc -l /usr/sbin/register-python-package 182 /usr/sbin/register-python-package It is a simple shell script. -- Florent
Re: Question about python policy
On Wed, 2004-02-11 at 02:14, Graham Wilson wrote: I think I'll do this for python-albatross as well. It'll be a really tiny package but at least it'll fix the issue of not being able to install both python 2.2 and 2.3 versions. Does it make sense to have both versions installed? Why might someone want to do that? The only situation that comes to mind is supporting applications written in an older dialect of python (ie. 2.2 vs. 2.3 and similar transitions in the future). While 2.2 code should run flawlessly on 2.3, there are some semantic differences (for example the introduction in 2.3 of the boolean type) that could cause unexpected behaviour. Therefore, having the option of keeping your old software running with python 2.2 while porting it to 2.3 (or writing a 2.3-based replacement) can be important to someone. And then there's the case of because we can. :) -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Question about python policy
Fabian Fagerholm [EMAIL PROTECTED] wrote: Hello all, Hi, Firstly, it seems a little silly to duplicate all the code in both packages. I guess there's really no other way of doing it, since there There used to be a tool called python-central (look in the mailing list archives) that allowed packages to ship pure-python modules *once* under /usr/lib/python/site-packages/ and have them automatically byte-compiled for the various pythonX.Y installed (through Debian packages, of course, your custom Python in /usr/local was not affected). It was said that it would integrate the main python packages after the initial proof of concept and testing period, but I never saw that happen. I don't know why. -- Florent
Question about python policy
Hello all, I maintain python-albatross, a python web toolkit (http://www.object-craft.com.au/projects/albatross). Following (the proposed) python policy, I've created a dummy package python-albatross, and two versioned packages, python2.2-albatross and python2.3-albatross. The dummy package depends on the 2.2 version. Now, I have some questions regarding this scheme. Firstly, it seems a little silly to duplicate all the code in both packages. I guess there's really no other way of doing it, since there are build-time test cases that should be run with each version of python, and the install-time bytecompiling and module optimizing that much be run with each version of python as well. Are there any ideas for how to reduce the size without making it all an unmaintainable mess? (python-albatross is quite small, but this may be useful for bigger packages.) Secondly, the above scheme makes it impossible to install both packages at the same time. This is because both packages provide the same initscript, defaults file and logrotate file. One solution, which may be against policy, is to have the versioned packages conflict with each other. Another solution would be to split all the common parts into a separate package, which is then depended upon by both versioned packages. But I don't know if this is permitted by the policy, or if it will introduce any side-effects that are undesirable. Perhaps it can be done, but should use versioned dependencies somehow? Please tell me what you think. Cheers, -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Question about python policy
On Tue, 2004-02-10 at 20:44, Graham Wilson wrote: This is the solution I use with the PyX package is to create a python-pyx-common package that both of the versioned packages depend on. This works fine for PyX, since the -common package just cotains read-only data files. I am not sure how well it would work for Albatross. I assume python-pyx-common doesn't include any python source code then. I think I'll do this for python-albatross as well. It'll be a really tiny package but at least it'll fix the issue of not being able to install both python 2.2 and 2.3 versions. Unless of course someone can either propose an even better way, or say why this solution will lead to horrific results. :) -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Question about python policy
On Tue, Feb 10, 2004 at 08:54:43PM +0200, Fabian Fagerholm wrote: On Tue, 2004-02-10 at 20:44, Graham Wilson wrote: This is the solution I use with the PyX package is to create a python-pyx-common package that both of the versioned packages depend on. This works fine for PyX, since the -common package just cotains read-only data files. I am not sure how well it would work for Albatross. I assume python-pyx-common doesn't include any python source code then. No, it doesn't. Just data files. I think I'll do this for python-albatross as well. It'll be a really tiny package but at least it'll fix the issue of not being able to install both python 2.2 and 2.3 versions. Does it make sense to have both versions installed? Why might someone want to do that? -- gram signature.asc Description: Digital signature
