On Fri, Dec 30, 2005 at 10:59:45PM -0600, Kenneth Pronovici wrote:
> What would you suggest doing about "hybrid" packages which are primarily
> applications, but also want to make their modules available to other
> Python programs? Two examples here are pychecker and epydoc (b
> About a month ago Steve Langasek and I discussed the state of Python
> packages on IRC, in particular the effects of bytecode compilation; the
> effectiveness (or lack thereof) of it, and how it tightens Python
> dependencies. I'd like to propose three changes to how Python modules
> are handled.
On Tue, Jul 12, 2005 at 10:26:09PM +0200, Josselin Mouette wrote:
> Le mardi 12 juillet 2005 à 14:35 -0500, Kenneth Pronovici a écrit :
> > I did some hacking on pychecker earlier this year, and it was really
> > nice to have 2.1, 2.2, 2.3 and 2.4 all available on the same Debian
On Mon, Jun 13, 2005 at 11:54:10AM -0700, Donovan Baarda wrote:
> On Sun, 2005-06-12 at 13:40, Martin Michlmayr wrote:
> > I once had a discussion with Matthias Klose about reducing the number
> > of Python versions in Debian and he said he'd like to get rid of 2.1
> > and 2.2 after sarge is out.
> Still need to be updated:
[...]
> * python-epydoc: the default package doesn't depend on python
I did the last NMU for python-epydoc because Moshe seems to be missing
in action (?); I can probably fix this problem as well.
Just to make sure I understand, I should be changing the python-epydoc
d
> for this scheme, you don't need to make /usr/bin/pychecker handle
> alternate python versions explicitly. Just put '#!/usr/bin/python' at
> the front, and the correct /usr/lib/pythonX.Y will be on the pythonpath.
> If they explicitly use a different python version by running;
>
> $ python2.1 /us
Hi,
I've taken over the pychecker package from Arto Jantunen, and I'm
looking over the remaining bugs. One of the three is #137320:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137320
It requests that the Pychecker modules be installed in the Python search
path, so they can be imported,
> In general, you have a single source package (e.g. python-pythoncard) which
> builds/installs for each available Python version (and Build-Depends on the
> -dev version for each of those, obviously) into a python-pythoncard
> package, and an empty python-pythoncard package that Depends on the
> c
> > > This is getting a bit more complicated than I expected it to be. I'd
> > > appreciate any advice you can give me.
> > I don't know why you split docs and samples, I'd put them in one package,
> > the samples go into /usr/share/doc//examples/. The doc package
> > depending on either of the li
> > I've now noticed that this doesn't conform to policy and I'm a little
> > confused about what packages I should provide.
> Only the name of the module package is against policy - it should be
> python-pythoncard.
I'm going to take this to mean python2.2-pythoncard/python2.3-pythoncard
based o
Hi,
I filed an ITP for PythonCard (http://pythoncard.sourceforge.net), and
I've made a first pass at packaging it. I built the following binary
packages:
libpythoncard-python
pythoncard-samples
pythoncard-doc
Each depends on python (>=2.2), python (<<2.3). The
libpythoncard-python pa
11 matches
Mail list logo
