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 pro
[restricting cc to -python]
Joey Hess wrote:
> 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
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
Hi,
It seems to be transition time for python packages ;-)
For the moment the default python bindings for gtk/gnome are 1.2
version. It means that an "import gtk" in a .py will load gtk1.2.
It's time to switch gtk/gnome 2 as the default bindings.
So all pygtk/gnome 1.2 programs have to use the
Hi, Donovan Baarda wrote:
> The only limitation is python-distutils requires the default
> python, ie you can't install python2.2-distutils without python (2.3)
> and hence python2.3.
I'd say we can live with that -- people who need an older Python version
installed for support of legacy applicat
If you use debhelper's dh_python, please make sure you use debhelper
(>= 4.1.60), which will be in the archives tonight.
Matthias
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 m
On Fri, 2003-08-08 at 22:31, Alexandre Fayolle wrote:
> 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)
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
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. B
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 a
On Fri, 2003-08-08 at 14:44, Matthias Urlichs wrote:
> Hi, Donovan Baarda wrote:
[...]
> > 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.
First I'd better qualify what I posted. The dependencies I po
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 or
On Fri, Aug 08, 2003 at 09:03:05AM +0200, Alexandre Fayolle wrote:
> 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.
>
> N
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
> (~/.
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 somewhe
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 depen
17 matches
Mail list logo