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 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: > 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
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
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
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:18:34PM +0200, Fabian Fagerholm wrote: > 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. [...] Another > solution would be to split all the common parts into a separate > package, which is then depended upon by both versioned packages. 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. -- gram signature.asc Description: Digital signature
