Questions regarding a package that creates a python module (written in C)
Dear Python developers,
I am a newbie with Python (though I like the language) and I help
maintain a package called fontforge, which is a font ("letters") editor
that creates two modules [*] written in C so that some tasks with fonts
can be performed en masse.
Unfortunately, even when depending on python-dev-all (or whatever I
should call it nowadays), I only get the modules created for python2.5
and I would like (in principle, barring technical limitations) to
provide such modules for any version of python that Debian supports,
agnostically.
It is my understanding from the build system of fontforge that it only
picks up python2.5 since it is the first version that is encountered.
With that said, what is the recommended course of action? Should I
manually build the package twice in a row in debian/rules telling it
first to configure with python 2.5 and then 2.6 or is there any solid,
recommended approach to this problem (which I am sure should appear in
many other packages that provide python modules written in C)?
Any guidance is welcome, Rogério Brito.
P.S.: Please, keep me on CC'ies as I am not currently subscribe to -python.
[*]
WARNING: WARNING: /usr/lib/pyshared/python2.5/fontforge.so is linked but does
not belong to any package.
WARNING: WARNING: /usr/lib/pyshared/python2.5/psMat.so is linked but does not
belong to any package.
but
,[ dpkg -S /usr/lib/pyshared/python2.5/fontforge.so ]
| python-fontforge: /usr/lib/pyshared/python2.5/fontforge.so
`
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526172853.ga19...@ime.usp.br
Re: Questions regarding a package that creates a python module (written in C)
* Rogério Brito , 2010-05-26, 14:28:
I am a newbie with Python (though I like the language) and I help
maintain a package called fontforge, which is a font ("letters") editor
that creates two modules [*] written in C so that some tasks with fonts
can be performed en masse.
Unfortunately, even when depending on python-dev-all (or whatever I
should call it nowadays), I only get the modules created for python2.5
and I would like (in principle, barring technical limitations) to
provide such modules for any version of python that Debian supports,
agnostically.
That's very nice of you. :)
It is my understanding from the build system of fontforge that it only
picks up python2.5 since it is the first version that is encountered.
Yes, most likely this is the case. I haven't seen any upstream build
system that supports building/installing module for multiple Python
version on its own initiative.
With that said, what is the recommended course of action? Should I
manually build the package twice in a row in debian/rules telling it
first to configure with python 2.5 and then 2.6
Yes. Please don't hardcorde version numbers in debian/rules, however;
use `pyversions -r` to query which Python versions are supported.
or is there any solid, recommended approach to this problem (which I am
sure should appear in many other packages that provide python modules
written in C)?
For distutils-based build systems (i.e., not for fontforge), dh(1)
builds modules for all supported Python versions (almost) out of the
box. I'm sure that cdbs has a way to automatize this task, too (though I
don't recommend cdbs to anyone).
--
Jakub Wilk
signature.asc
Description: Digital signature
Python and python3 as separate runtime systems
This has been discussed a bit, but I'd like to see where Debian Python consensus is on this. I think users who don't care about Python 3 yet, should be able to have systems that don't pull any Python 3 elements on by accident. Python 3 is primarily of interest to developers right now and most users won't care to have it. It is very unusual for code to be able to run unmodified in both Python 2 and Python 3. I think it makes sense for them to be kept separate at runtime. This would mean separate python-foo and python3-foo binaries where both are supported from the same source. It would mean that binaries should not depend on both Python 2 and Python 3 interpreters. I means that the support tools for Python 3 should run in Python 3 As an example, I've done a first cut at py3versions: http://www.kitterman.com/debian/ This will also, in the very long run, make it easier to transition to a Python 3 version as the default Python. Thoughts, Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005261743.43894.deb...@kitterman.com
RFS: pyevolve
Hello, I am looking for a sponsor for my package "pyevolve". * Package name: pyevolve Version : 0.6~rc1~svn397+dfsg-1 Upstream Author : Christian S. Perone * URL : http://pyevolve.sourceforge.net * License : Python License (with upstream subsituted for PSF) Section : python It builds these binary packages: python-pyevolve - Complete genetic algorithm framework written in pure python python-pyevolve-doc - Documentation for the Pyevolve genetic algorithm framework The package appears to be lintian clean. The upload would fix these bugs: 580924 Pyevolve is one of the most complete genetic algorithm frameworks currently available. It is trivially easy to use out-of-the-box and yet easily extendable. It also provides extensive documentation. For a good overview of Pyevolve's feautres and capabilities, see ACM SIGEVOlution Volume 4 Issue 1, available at http://www.sigevolution.org. Upstream is very responsive. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pyevolve - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pyevolve/pyevolve_0.6~rc1~svn397+dfsg-1.dsc I would be glad if someone uploaded this package for me. Thanks, Christian signature.asc Description: OpenPGP digital signature
Re: Python and python3 as separate runtime systems
* Scott Kitterman , 2010-05-26, 17:43: I think users who don't care about Python 3 yet, should be able to have systems that don't pull any Python 3 elements on by accident. Python 3 is primarily of interest to developers right now and most users won't care to have it. It is very unusual for code to be able to run unmodified in both Python 2 and Python 3. I think it makes sense for them to be kept separate at runtime. This would mean separate python-foo and python3-foo binaries where both are supported from the same source. It would mean that binaries should not depend on both Python 2 and Python 3 interpreters. I means that the support tools for Python 3 should run in Python 3 Seconded. -- Jakub Wilk signature.asc Description: Digital signature
Re: Python and python3 as separate runtime systems
On May 26, 2010, at 05:43 PM, Scott Kitterman wrote: >I think it makes sense for them to be kept separate at runtime. > >This would mean separate python-foo and python3-foo binaries where both are >supported from the same source. > >It would mean that binaries should not depend on both Python 2 and Python 3 >interpreters. +1 -Barry signature.asc Description: PGP signature
Re: Python and python3 as separate runtime systems
Il 26/05/2010 23.43, Scott Kitterman ha scritto: > This would mean separate python-foo and python3-foo binaries where both are > supported from the same source. > > It would mean that binaries should not depend on both Python 2 and Python 3 > interpreters. ACK. Having a safety new provided by NEW processing would introduce lesser bugs and a smoother transition. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
