Re: Python packages in incoming
On Sun, Oct 14, 2001 at 10:57:25AM +0200, Matthias Klose wrote:
> Jérôme Marant writes:
> > What about proposal and policy from Neil and his efforts?
> - the proposed packaging scheme doesn't allow smooth upgrades between
> one python version and a next version. compare python-1.5 to libc5
> and python-2.1 to libc6.
Supporting partial upgrades and supporting smooth upgrades are different
things. Also, in the above situation you'll note all the lib*g and
-altdev packages we were forced to have.
] python-2.1_2.1.1
] python_2.1.1 (depends on python-2.1) (does "ln /usr/bin/python{2.1,}")
] python-2.1-_ (depends on python-2.1)
] python-_ (depends on python and python-2.1-)
Hrm. That should be:
Package: python-
Version:
Depends: python (>= 2.1), python (<< 2.2), python-2.1-
The versioned deps are important. Actually, the versioning is a bit more
complicated too, and would need to be:
Version: +
or something similar, to ensure upgrades work right. Although you might be
able to get away with:
Version: -2.1-
] _ (depends on python and python-,
] #!/usr/bin/python)
] -2.1_ (depends on python-2.1 and
] python-2.1-, #!/usr/bin/python2.1)
> there was a clear upgrade procedure to do
> the transition. The proposed packaging scheme doesn't allow such an
> upgrade. From my point of view, this is a showstopper.
The transition to python_2.2.1 (say), in the above would seem to be to
rebuild all of the python module's against 2.2, and upload them. When
they're all uploaded (or all the ones you use are uploaded), you can
upgrade python.dev, and python-.deb all at once, and you'll go
from a consistently 2.1-based system to a consistently 2.2-based system.
There aren't really any better scenarios if you can only use 2.1-based
modules with python 2.1, and 2.2-based modules with python 2.2. In
particular, this is ensured simply by having the right dependencies. You
could maybe have some scripts that use python2.1 and python2.1 modules,
and others that use python2.2 and python2.2 modules, but then you have
to expect scripts to have the version of python they use hardcoded for
no good reason, and things start getting pretty ugly.
The proposed scheme also allows you to have different versions of python
and its modules installed concurrently, although scripts from Debian
will only ever use the version matching python.deb.
It does have the bad property that it duplicates every module package,
though. That's a trade off between whether you want to automatically
support people running two different versions of python on the one machine
or not, afaics, you either get one or the other (or you make it hard for
people to refer to the packages at all, like Depends: python | python2 |
python21 | python30 | ...; Provides: would stop you from being able to use
dependencies to ensure your system is consistent).
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]>
libwxgtk2.2-python
Hello, the wxgtk maintainer asked me to foreward the following questions to this list: > From [EMAIL PROTECTED] Tue Oct 16 11:31:09 2001 > > What I'd really like to know is that (by far) > most of the people currently using it with 1.5 will be happy that > it is now built with 2.1 In my opinion a package linked against 2.1 packages would be better, but I´m not really sure. I personally had success compiling a program with python 2.0 and wxgtk-python by just ln -s ../../python1.5/site-packages/wxPython /usr/lib/python2.0/site-packages/wxPython For sure this is no real solution. If you think that two separate wxgtk versions are really necessary please speak now because Ron is preparing packages for a new version. > And that there are no continuing licence issues with python2 that > would cause a problem here. I think this problem vanished. > If there is consensus about these two issues, then I'll be happy > to do whatever the majority of wxPython developers would like. Any hints for Ron? (Please make sure to CC: him personally because he is not subscribed. Kind regards Andreas.
Re: libwxgtk2.2-python
On Tue, Oct 16, 2001 at 11:39:38AM +0200, Tille, Andreas wrote: > If you think that two separate wxgtk > versions are really necessary please speak now because Ron is preparing > packages for a new version. Just to be completely clear about this, I almost certainly will not consider having *both* 1.5 and 2.x versions of wxPython in the archive together. It will be one or the other, but which is pretty much up to you people (pending the all clear on the licence issue). wx has enough *unique* permutations to not want to start doubling them up, so anyone who wants the other will probably have to rebuild the package themselves. sorry, but I'm sure you can understand. thanks, Ron (yes, CC me, I'm not on the list)
What should we do now?
Hi, The latest upgrade worked fine for me. Thanks to Gregor and Matthias ;-) What should python modules packagers do now? Should we stop providing support for python2 and provide python2.1 versions of our modules now? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> CV consultable à l'adresse : http://marant.org
Second report: latest python in unstable broke my packages
Hi, I said previously that the upgrade when OK. This is true, but I hadn't look further at that moment. I installed both python1.5 and python2.1. And installing both on the same system broke _all_ my python 1.5 packages: this is the alternative issue Perl people have warned us about. I discovered that /usr/bin/python is pointing to python2.1, so running those python 1.5 scripts makes them fail. FYI, my packages are python-4suite and python-xml. Was that issue expected? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> CV consultable à l'adresse : http://marant.org
Re: Second report: latest python in unstable broke my packages
Jérôme Marant wrote: I said previously that the upgrade when OK. This is true, but I hadn't look further at that moment. My upgrade had some errors: File "/usr/lib/python2.1/test/nocaret.py", line 2 [x for x in x] = x SyntaxError: can't assign to list comprehension SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3)
Re: Second report: latest python in unstable broke my packages
Hi, On 16 Oct 2001, Jérôme Marant wrote: <...> > I installed both python1.5 and python2.1. And installing both on the same > system broke _all_ my python 1.5 packages: this is the alternative issue > Perl people have warned us about. > > I discovered that /usr/bin/python is pointing to python2.1, so running those > python 1.5 scripts makes them fail. > > FYI, my packages are python-4suite and python-xml. > > Was that issue expected? Yes. It seems to be a convention issue. how's this... If a program requires python1.5 (or any specific version of Python), it should do so explicitly. #!/usr/bin/env python1.5 or #!/usr/bin/python1.5 [arg list] The first form lets the program work with a Python-1.5 installed anywhere on the PATH, he second is required if options need to be passed to the interpreter. Scripts that call Python-1.5 code need to do: python1.5 some1.5dependentcode.py Users wanting to do, "python some1.5code.py", will need to either: be given a wrapper that does "exec python1.5 ..." (whatever works best), or live with using "python1.5 ..." (and having to remember which Python is linked to "python"?).:-( :-( Best if users don't need to do "python aversiondependent.py", is that realistic? Code depending on Python-2.x can use the virtual "python2" interpreter; provided by any 2.x package, managed by alternatives or maybe a debconf interface and some utilities (?). A "python1" should not be necessary, but a "python3" may be when the potentially code-breaking Python-3.0 is released. A plain "python" would only be usable by code that works with any version of Python included in the stable archive. - Bruce
Re: What should we do now?
[Currently I am unable to read new incoming mails ... I'll respond later to other messages] Just uploaded a new python1.5 NMU which fixes three bugs I introduced. Jérôme Marant writes: > What should python modules packagers do now? > Should we stop providing support for python2 and provide > python2.1 versions of our modules now? - should we ship with the 2.0 packages? - for now the safest thing would be separate 2.1 packages, which are built independently from 2.0. So if we decide that 2.0 should not be shipped with woody, then we can simply remove them.
Re: Second report: latest python in unstable broke my packages
Bastian Kleineidam writes: > Jérôme Marant wrote: > > > I said previously that the upgrade when OK. This is true, but I hadn't > > look > > further at that moment. > > > My upgrade had some errors: No errors. The postinst just compiled the testsuite. Btw, do we really need the testsuite as a package? It's included in the source as well ..
Re: libwxgtk2.2-python
Ron writes: > On Tue, Oct 16, 2001 at 11:39:38AM +0200, Tille, Andreas wrote: > > If you think that two separate wxgtk > > versions are really necessary please speak now because Ron is preparing > > packages for a new version. > > Just to be completely clear about this, I almost certainly will > not consider having *both* 1.5 and 2.x versions of wxPython in > the archive together. It will be one or the other, but which is > pretty much up to you people (pending the all clear on the licence > issue). if you repackage wxpython, please package it as an package which has an upstream version (and an .orig.tar.gz).
Re: Python packages in incoming
Anthony Towns writes:
> ] python-2.1_2.1.1
> ] python_2.1.1 (depends on python-2.1) (does "ln /usr/bin/python{2.1,}")
> ] python-2.1-_ (depends on python-2.1)
> ] python-_ (depends on python and python-2.1-)
>
> Hrm. That should be:
>
> Package: python-
> Version:
> Depends: python (>= 2.1), python (<< 2.2), python-2.1-
>
> The versioned deps are important. Actually, the versioning is a bit more
> complicated too, and would need to be:
>
> Version: +
And for a zope module ++ ;-?
> or something similar, to ensure upgrades work right. Although you might be
> able to get away with:
>
> Version: -2.1-
>
> ] _ (depends on python and python-,
> ] #!/usr/bin/python)
> ] -2.1_ (depends on python-2.1 and
> ] python-2.1-, #!/usr/bin/python2.1)
>
> > there was a clear upgrade procedure to do
> > the transition. The proposed packaging scheme doesn't allow such an
> > upgrade. From my point of view, this is a showstopper.
>
> The transition to python_2.2.1 (say), in the above would seem to be to
> rebuild all of the python module's against 2.2, and upload them. When
> they're all uploaded (or all the ones you use are uploaded), you can
> upgrade python.dev, and python-.deb all at once, and you'll go
> from a consistently 2.1-based system to a consistently 2.2-based system.
For my understanding:
- we do have versioned packages for each package, which is built from
the pythonX.Y package:
python1.5-base python2.1-base
python1.5-tkpython2.1-tk
python1.5-gdbm python2.1-gdbm
... ...
- If a module is provided as a versioned package, then there must be
an unversioned package as well, which depends on the most recent
working version of the versioned package.
So we will have at least python-tk, python-gdbm, etc ...
Same for python-base and python-dev.
Versioned "third party" modules are needed, if different
versions of the modules are needed (i.e numpy-20 doesn't work
with python1.5, only numpy-17 does).
> There aren't really any better scenarios if you can only use 2.1-based
> modules with python 2.1, and 2.2-based modules with python 2.2. In
> particular, this is ensured simply by having the right dependencies. You
> could maybe have some scripts that use python2.1 and python2.1 modules,
> and others that use python2.2 and python2.2 modules, but then you have
> to expect scripts to have the version of python they use hardcoded for
> no good reason, and things start getting pretty ugly.
>
> The proposed scheme also allows you to have different versions of python
> and its modules installed concurrently, although scripts from Debian
> will only ever use the version matching python.deb.
Assume I have installed
- python-dev (1.5.x), depending on python1.5-dev
- python-dev (2.1.x), depending on python2.1-dev
- python points to python1.5
- python-foo was just converted to depend on python (>=2.1, << 2.2).
- the new python-foo doesn't work with python1.5 anymore.
If the unversioned python binary is used in python-foo, then this
package won't work (assume I have to use the new python-foo to build a
new python-bar). I don't see how we can enforce this without calling
the versioned python binary in the python-foo package. And there's no
problem to replace the binary [1].
> It does have the bad property that it duplicates every module package,
> though. That's a trade off between whether you want to automatically
> support people running two different versions of python on the one machine
> or not, afaics, you either get one or the other (or you make it hard for
> people to refer to the packages at all, like Depends: python | python2 |
> python21 | python30 | ...; Provides: would stop you from being able to use
> dependencies to ensure your system is consistent).
well, a release should never ship with more than two
versions: The python version from the last release and a recent
version, so you have two support two dependencies.
you won't need to duplicate packages,
- if it's an arch independant package
- if the module version builds with both/all python versions
- if we have a mechanism how to to register/unregister a
module for different python versions.
But this is something which could be delayed after the woody release.
Matthias
[1]
cd debian && \
for i in `find -mindepth 2 -type f`; do \
sed '1s,#!.*python[^ ]*\(.*\),#! /usr/bin/python$(VER)\1,' \
$$i > $$i.temp; \
if cmp --quiet $$i $$i.temp; then \
rm -f $$i.temp; \
else \
mv -f $$i.temp $$i; \
chmod 755 $$i; \
echo "fixed interpreter: $$i"; \
fi; \
done
Re: libwxgtk2.2-python
Matthias Klose wrote: Ron writes: On Tue, Oct 16, 2001 at 11:39:38AM +0200, Tille, Andreas wrote: If you think that two separate wxgtk versions are really necessary please speak now because Ron is preparing packages for a new version. Just to be completely clear about this, I almost certainly will not consider having *both* 1.5 and 2.x versions of wxPython in the archive together. It will be one or the other, but which is pretty much up to you people (pending the all clear on the licence issue). I'd prefer the latest python and wxpython (and wxwindows-c++), assuming there aren't any critical bugs. Brendan Simon.
Re: Second report: latest python in unstable broke my packages
Quoting Bruce Sass <[EMAIL PROTECTED]>: > Hi, > > On 16 Oct 2001, Jérôme Marant wrote: > <...> > > I installed both python1.5 and python2.1. And installing both on the > same > > system broke _all_ my python 1.5 packages: this is the alternative > issue > > Perl people have warned us about. I didn't think the new packages were using alternatives? > > I discovered that /usr/bin/python is pointing to python2.1, so > running those > > python 1.5 scripts makes them fail. [...] looking at the current unstable Packages file, it looks like the updates to python2.1 are not in there yet. If they are, then they haven't been done as well as the python1.5 packages. I've only looked at the Packages file so far, so I might have missed something. The python1.5 packages look like they are well structured for a clean transition. python-base (1.5.2-18.1) depends python1.5-base, provides python python1.5-base (1.5.2-18.1) provides python1.5, replaces python-base (<=1.5.2- 17), conflicts python-base (<=1.5.2-7) This will safely replace the old python-base, replacing it with python1.5-base. The new python-base presumably establishes python1.5 as the default /usr/bin/python. Note that the new python-base has a comment that suggests it is a transition package that can be removed later on. I'm not sure that this is correct, as it effectively provides the dependancies that other non-version specific python modules and applications can depend on (ie python- base and/or python). The python2.1 packages must not be updated yet; python2-base, provides python2 python2.1-base provides python2.1 No conflicts/replaces etc. These two packages could be installed together, except that they over-write each others files. > > FYI, my packages are python-4suite and python-xml. > > > > Was that issue expected? > > Yes. > > It seems to be a convention issue. I had to laugh at this... :-) Without an up to date Python policy, how can anybody know of the conventions, or even have any? Niels initial attempt had flaws, but at least it was an attempt. I'd like to see it updated. Even thought the existing 1.5 packages seem OK, they raise some questions. Should version independant packages depend on python or python-base? The same with version dependant packages; python1.5 or python1.5-base? How are version independant modules going to be handled, or are all modules going to be tied to a particular version? The additions of these "provides" was IMHO redundant. > Code depending on Python-2.x can use the virtual "python2" > interpreter; provided by any 2.x package, managed by alternatives > or maybe a debconf interface and some utilities (?). A "python1" > should not be necessary, but a "python3" may be when the potentially > code-breaking Python-3.0 is released. This is neat. I take it this means there will be a wrapper package python2-base that selects a particular /usr/bin/python2.Y as the default /usr/bin/python2 -- ABO: finger [EMAIL PROTECTED] for more information.
Re: Python packages in incoming
Quoting Matthias Klose <[EMAIL PROTECTED]>:
> Anthony Towns writes:
> > ] python-2.1_2.1.1
> > ] python_2.1.1 (depends on python-2.1) (does "ln
> /usr/bin/python{2.1,}")
> > ] python-2.1-_ (depends on python-2.1)
> > ] python-_ (depends on python and
> python-2.1-)
> >
> > Hrm. That should be:
> >
> > Package: python-
> > Version:
> > Depends: python (>= 2.1), python (<< 2.2), python-2.1-
> >
> > The versioned deps are important. Actually, the versioning is a bit
> more
> > complicated too, and would need to be:
> >
> > Version: +
>
> And for a zope module ++
> ;-?
[...]
Nah... it doesn't have to be that complicated unless you want it to be.
Remember python- is just a wrapper package to provide a dependancy for
version-independant packages so they can have "Depends: python, python-
" and be sure they use a compatible pair of pythonX.Y and pythonX.Y-
. Anything that does rely on a particular version of python-
should have "Depends: pythonX.Y-". This means you can just use;
Version: -
Sure, at some point the default python will change from pointing at python1.5
to python2.1, so python- will have to change to depend on the new
python2.1-, but why does this need to be more than just a change?
> For my understanding:
>
> - we do have versioned packages for each package, which is built from
> the pythonX.Y package:
>
> python1.5-base python2.1-base
> python1.5-tkpython2.1-tk
> python1.5-gdbm python2.1-gdbm
> ... ...
>
> - If a module is provided as a versioned package, then there must be
> an unversioned package as well, which depends on the most recent
> working version of the versioned package.
Correction... which depends on the current "default" version of the versioned
package, which must correspond with the "default" version specified by the
corresponding python-base package. There might be working python2.1 packages
available, but still have python1.5 as the default.
> So we will have at least python-tk, python-gdbm, etc ...
> Same for python-base and python-dev.
Yep.
> Versioned "third party" modules are needed, if different
> versions of the modules are needed (i.e numpy-20 doesn't work
> with python1.5, only numpy-17 does).
This is optional.
Third party modules have the choice of producing versioned modules with a
default specified by a wrapper package as above, or they can produce a single
un-versioned package that has "Depends: pythonX.Y-base". Note that if they
choose the second option, they are tying their module to a particular version
of python, so any other packages that use this module will also be tied to that
version and must have "Depends: pythonX.Y-base, ". A sort of
half way option would be to produce multiple versioned packages, but not
provide a default wrapper. This would make any packages that depend on it tied
to a particular version of python, but they would have the option of which
version to tie to.
Note this assumes the module has to be compiled/linked against a particular
version of python. If the module is actually version independant, then you can
use a single package that just has "Depends: python-base", installs itself
into /usr/lib/python/, and symlinks and compiles it's *.py files into all
the /usr/lib/pythonX.Y/ directorys. Obviously this would be much easier for
package developers if python-base provided a script to do this that could be
called in third-party post-inst scripts. This script would also need to be
called every time a new pythonX.Y-base was installed.
> > There aren't really any better scenarios if you can only use 2.1-based
> > modules with python 2.1, and 2.2-based modules with python 2.2. In
> > particular, this is ensured simply by having the right dependencies.
> You
> > could maybe have some scripts that use python2.1 and python2.1
> modules,
> > and others that use python2.2 and python2.2 modules, but then you have
> > to expect scripts to have the version of python they use hardcoded for
> > no good reason, and things start getting pretty ugly.
> >
> > The proposed scheme also allows you to have different versions of
> python
> > and its modules installed concurrently, although scripts from Debian
> > will only ever use the version matching python.deb.
>
> Assume I have installed
> - python-dev (1.5.x), depending on python1.5-dev
> - python-dev (2.1.x), depending on python2.1-dev
Typo? how can you have two python-dev's installed? Did you mean;
- python (1.5.x), depending on python1.5
- python-foo (1.5.x), depending on python1.5-foo, python (>=1.5,<<2.0)
> - python points to python1.5
> - python-foo was just converted to depend on python (>=2.1, << 2.2).
> - the new python-foo doesn't work with python1.5 anymore.
>
> If the unversioned python binary is used in python-foo, then this
> package won't work (assume I have to use the new python-foo to build a
> new python-bar). I
