Re: version independent pythin packages: ?
Hi, Donovan Baarda wrote:
It seems each individual package should be responsible for compiling
it's own *.py's with an appropriate version of python, even in
/usr/lib/python. We can't have the python package handle it directly.
Hmm. Correct. See below.
Try the following set of dependencies;
OK, for one, docutils isn't supported for python 2.2, so all those long
lines get a bit shorter.
I think the 'dependency package' approach works best.
Package: python-docutils
Architecture: all
Depends: python2.3-docutils | python2.2-docutils
Description: Utilities for the documentation of Python modules
The purpose of the Docutils project is to create a set of tools for
processing plaintext documentation into useful formats, such as HTML,
XML, and TeX.
.
The package includes the reStructuredText parser and the Python
Docstring Processing System project.
Package: python2.3-docutils
Architecture: all
Depends: python2.3, python-docutils, python-roman
Description: Dependency package for python-docutils with Python 2.3
This package is a dependency package. It represents the requirements of
the python-docutils package when used with Python 2.3.
Package: python2.2-docutils
Architecture: all
Depends: python2.2, python-docutils, python2.2-xmlbase, python-roman,
python-textwrap
Description: Dependency package for python-docutils with Python 2.2
This package is a dependency package. It represents the requirements of
the python-docutils package when used with Python 2.2.
If there's no objection, the next version will look like this.
(Due out shortly, as I need to package upstream's 0.3 as well as fix a
packaging bug.)
Package: python-xmlbase
Depends: python (2.3) | python2.2 | python2.1 | python2.0 | python1.6
| python1.5
Provides: python2.2-xmlbase, python2.1-xmlbase, python2.0-xmlbase,
python1.6-xmlbase, python1.5-xmlbase
Duh? xmlbase doesn't seem to be supported for Python 2.1.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
I could not love thee, dear, so much, loved I not honor more.
-- Richard Lovelace
Re: /usr/include/python
On Fri, 2003-08-08 at 00:25, Matthias Klose wrote: why isn't there a default /usr/include/python (possibly accomplished as a symlink in the package python-dev, like /usr/bin/python in the package python)? (I'm sure there is a reason for that, I just didn't find it documented somewhere.) it's not needed. distutils selects the correct include path for you. I just encountered some stupid build environment (SAPDB) which sets up its own PYTHONPATH and relies on /usr/include/python. Well, there are other ways around that. Thanks! bye, Roland signature.asc Description: This is a digitally signed message part
Re: version independent pythin packages: ?
On Thu, Aug 07, 2003 at 11:34:27AM +0100, Ricardo Javier Cardenes Medina wrote:
Thinking on this problem a bit further (not feasible with current
implementation), wouldn't it be nice if the user could enable Python
(via environment or command line switch) to use some local repository
(~/.python/X.Y/) to store .py{c,o} files if (s)he hasn't write access to
the system files?
You always can copy the .py[co] files in
/usr/lib/python2.X/site-packages at install time. Since these directory
come before /usr/lib/site-python in the default sys.path, the compiled
modules will be used on import.
Now this has some unpleasant consequences:
* python no longer has a way of seeing if the .pyc is up to date
* I think this screws up the exception reporting routines in python
Maybe this could be handled with symlinks?
--
Alexandre Fayolle
LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Développement logiciel avancé - Intelligence Artificielle - Formations
Re: version independent pythin packages: ?
Ricardo Javier Cardenes Medina writes: Of course, all this require manual handling from the user. What I was proposing would require a whole PEP and some reasonable design and implementation, etc, so Python itself could map those .pyc to their original file, only resorting to them if the original .py/.pyc are not synced; deleting them if they're not usefult any more, etc. PEP304
Re: version independent pythin packages: ?
On Fri, 2003-08-08 at 12:50, Donovan Baarda wrote: On Thu, 2003-08-07 at 18:44, Alexandre Fayolle wrote: On Thu, Aug 07, 2003 at 12:58:25PM +1000, Donovan Baarda wrote: [...] Python applications using the default Python with their own modules not in /usr/lib/site-python... not an issue? Actually... I think I prefer /usr/lib/python/site-packages rather than /usr/lib/site-python because that way the directory structure mirrors that for the /usr/lib/pythonX.Y specific version tree. Having just looked at a few packages, it seems /usr/lib/site-python is already well on the way to becoming the default location for version independent modules. Please forget I said the above :-) -- Donovan Baarda [EMAIL PROTECTED]
Re: version independent pythin packages: ?
Hi,
Donovan Baarda wrote:
If there's no objection, the next version will look like this.
(Due out shortly, as I need to package upstream's 0.3 as well as fix a
packaging bug.)
Um... I have a few problems with this. It doesn't really follow the
current Python Policy.
True. But then IMHO the policy might be amenable to changing. This is why I
posted here...
After writing this I had a look at the current docutils package and
think I know what you are getting at. python-docutils puts all the
modules in /usr/lib/site-python and the other guys just make sure the
dependencies are met.
Right...
For some reason I feel a bit uncomfortable with it. The python-docutils
package doesn't support the default python. Installing
python-docutils, python2.3-docutils, and python (2.2) will meet all
dependencies but result in a docutils that doesnt work for
/usr/bin/python.
You're right. *Sigh*.
I'm not sure what the best solution is. My gut instinct is to have
python-docutils just depend on python-xmlbase and python-textwrap, and
have python (2.3) Provides them. That way you could have;
The problem I have with that is that there are quite a few modules which have
been canonized in 2.2, and more in 2.3, and next year there'll be more in
2.4. You can't back-change sarge's python2.2 package to include yet another
Provides: python-foo which is already included in python 2.3 but which
somebody has separated out in order to support python-foobar on older Python
installations.
It would be nice if you could specify dependencies as follows;
Depends: (python2.2, python2.2-xmlbase, python-textwrap) | (python2.3),
python-roman
Hmm. You can, just distribute the stuff out (standard Boole algebra):
Depends: python2.3 | python2.2, python2.2-xmlbase | python2.3,
python-textwrap | python2.3, python-roman
It looks ugly as hell, though, and I'll have to check whether it really does
the right thing when you have python2.2 installed and pull in
python-docutils.
It gets even worse if I decide to support Python versions 2.3, but that
doesn't seem to be helpable.
I was going to suggest a solution, but I'm tired and I can't think of
one. docutils is a tough one :-(
Yes, it's an interesting testcase for changing policy. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: Das Zitat wurde zufllig ausgewhlt. | http://smurf.noris.de
--
Frage an Radio Eriwan:
Was ist der Unterschied zwischen einem Optimisten und einem Pessimisten?
Antwort: Der Optimist lernt Englisch, der Pessimist chinesisch.
Re: version independent pythin packages: ?
On Fri, Aug 08, 2003 at 01:52:40PM +0200, Matthias Urlichs wrote: Hi, Donovan Baarda wrote: It would be nice if you could specify dependencies as follows; Depends: (python2.2, python2.2-xmlbase, python-textwrap) | (python2.3), python-roman Hmm. You can, just distribute the stuff out (standard Boole algebra): Depends: python2.3 | python2.2, python2.2-xmlbase | python2.3, python-textwrap | python2.3, python-roman It looks ugly as hell, though, and I'll have to check whether it really does the right thing when you have python2.2 installed and pull in python-docutils. I'm not sure this will work if I try to use docutils as a library in another package supporting only python2.2. Initially installed packages: python2.3 I apt-get install python2.2-so-and-so which Depends: python2.2, python-docutils python2.2 will be installed, so is python-docutils, but not python-textwrap nor python2.2-xmlbase because python2.3 is there. The result is a malfunctionning python2.2-so-and-so, unless the packager manually adds python-textwrap and python2.2-xml dependencies, but this feels wrong to me. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: version independent pythin packages: ?
On Fri, Aug 08, 2003 at 11:05:09AM +0200, Matthias Klose wrote: Ricardo Javier Cardenes Medina writes: Of course, all this require manual handling from the user. What I was proposing would require a whole PEP and some reasonable design and implementation, etc, so Python itself could map those .pyc to their original file, only resorting to them if the original .py/.pyc are not synced; deleting them if they're not usefult any more, etc. PEP304 Heh... Deep in my heart I knew someone had been thought this before. :-) It's just of common sense :D
using debhelper's dh_python and python-2.3
If you use debhelper's dh_python, please make sure you use debhelper (= 4.1.60), which will be in the archives tonight. Matthias
Re: python 2.2 - python 2.3 transition
Josip Rodin wrote: Am I the only one who has a disgusting reminiscence of netscape*.* packages every time python* is mentioned? :P Actually I'm more reminded of the perl* packages and the complete mess that followed. And I keep expecting to see the same set of problems affect python. -- see shy jo pgpXISG37Hhdy.pgp Description: PGP signature
Re: python 2.2 - python 2.3 transition
Joey Hess writes: Josip Rodin wrote: Am I the only one who has a disgusting reminiscence of netscape*.* packages every time python* is mentioned? :P Actually I'm more reminded of the perl* packages and the complete mess that followed. And I keep expecting to see the same set of problems affect python. I'd like to see a way how to ease transitions between major version of basic packages. It is an problem, if accumulated transitions prohibit the migration of packages to testing. libgdbm recently broke the migrations, glibc-2.3.1 broke the transition for about half a year. maybe it's time to define a set of basic packages on which a Debian release is based on and then rebuild a new release on this basic-sid-or-whatever release. Matthias
