a
>package like pygtk2 comes to mind, having many rdepends).
>We still do have the limitation, that every python module depending
>on a pythonX.Y-foo binary-arch package cannot use the packaging
>infrastructure.
Two comments here. First, I don't think all python exten
On Thu, 2006-02-02 at 21:09 +0100, Matthias Klose wrote:
> > that is, packages with private modules but without extension modules
> > and no modules in /usr/lib/python2.x. how many packages are this?
2006/2/3, Joe Wreschnig <[EMAIL PROTECTED]>:
> Off the top of my head and in no particular order:
On Thu, 2006-02-02 at 23:02 +0100, Josselin Mouette wrote:
> Le jeudi 02 février 2006 à 21:09 +0100, Matthias Klose a écrit :
> > Josselin Mouette writes:
> > > There is still a situation we can improve easily, though: private
> > > modules. Currently, they have to migrate with python transitions,
Le jeudi 02 février 2006 à 21:09 +0100, Matthias Klose a écrit :
> Josselin Mouette writes:
> > There is still a situation we can improve easily, though: private
> > modules. Currently, they have to migrate with python transitions, and
> > this is only because of byte-compilation. The python-suppor
On Thu, 2006-02-02 at 21:09 +0100, Matthias Klose wrote:
> Josselin Mouette writes:
> > There is still a situation we can improve easily, though: private
> > modules. Currently, they have to migrate with python transitions, and
> > this is only because of byte-compilation. The python-support way of
Josselin Mouette writes:
> There is still a situation we can improve easily, though: private
> modules. Currently, they have to migrate with python transitions, and
> this is only because of byte-compilation. The python-support way of
> doing things should still be fine for them, and it can reduce
Le jeudi 26 janvier 2006 à 15:26 +0100, Matthias Klose a écrit :
> While preparing some example packages to experiment with
> python-central and python-support, I did see some issues with both
> proposals, in that the dependencies are not fulfilled for every python
> version that both packaging sys
While preparing some example packages to experiment with
python-central and python-support, I did see some issues with both
proposals, in that the dependencies are not fulfilled for every python
version that both packaging systems claim to support. Feedback is
welcome.
For an example see python-pm
Steve Langasek writes:
> On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> > Steve Langasek writes:
> > > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
>
> > > > the design decision of putting the binary-all python packages in a
> > > > separate directory into /va
On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > > the design decision of putting the binary-all python packages in a
> > > separate directory into /var/lib/python2.x/site-packages has s
Steve Langasek writes:
> On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > Josselin Mouette writes:
> > > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > > > This is the right direction, and adding support for extensions makes
> > > > this complete. Does your
On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> Josselin Mouette writes:
> > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > > This is the right direction, and adding support for extensions makes
> > > this complete. Does your proposal allow rebuilding these p
Josselin Mouette writes:
> Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit :
> As I already explained on IRC, dh_python will not hand .py files to
> python-support in architecture-dependent packages containing a .so
> module. This is unnecessary and would bring issues like this on
Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit :
> the design decision of putting the binary-all python packages in a
> separate directory into /var/lib/python2.x/site-packages has some
> problems when supporting packages with extensions (a proposal beeing
> made on #irc was to k
Josselin Mouette writes:
> Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > This is the right direction, and adding support for extensions makes
> > this complete. Does your proposal allow rebuilding these packages
> > without actually changing anything (except the changelog).
>
Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > Python-support already handles private modules. As for extensions, I
> > don't think we should change the current packaging practise. Packaging
> > them is already complicated enough as it is.
>
> yes, a reason to simplify this.
Josselin Mouette writes:
> > correct, but making it easier for extensions and applications using
> > private modules as well. when will python-support be able to support
> > these?
>
> Python-support already handles private modules. As for extensions, I
> don't think we should change the current p
Le lundi 16 janvier 2006 à 12:40 +0100, Matthias Klose a écrit :
> > Looking at the mailing list archives, some people have tried to initiate
> > discussions about making python in Debian evolve in the recent months,
> > but it doesn't look like there has been much interest.
>
> please see debian-
On Mon, Jan 16, 2006 at 12:40:09PM +0100, Matthias Klose wrote:
> Josselin Mouette writes:
> > Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> > > - beeing able to support more python versions in a separate archive
> > > is not just aesthetic (although not needed in the dist
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> > sorry, what is complicated about the solution?
> >
> > please read again, these benefits aren't just aesthetic:
> >
> > - working on metadata without having all packages available (which
> > ones?
Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> sorry, what is complicated about the solution?
>
> please read again, these benefits aren't just aesthetic:
>
> - working on metadata without having all packages available (which
> ones?) is not just aesthetic.
What exactly
On Fri, 2006-01-13 at 12:44 +0100, Matthias Klose wrote:
> Joe Wreschnig writes:
> > One issue that comes to my mind now is behavior with regards to
> > dpkg-divert. I've diverted a number of Python modules on my system;
> > under this centralized registry I would have to divert them for all
> > ve
Matthias Klose wrote:
> Josselin Mouette writes:
> > Furthermore, if you want to see this implemented, you'll have to find
> > someone else to write the necessary changes to dh_python. I will not
> > write nor maintain any code that parses the control file in dh_python.
> > This script is already o
Josselin Mouette writes:
> Furthermore, if you want to see this implemented, you'll have to find
> someone else to write the necessary changes to dh_python. I will not
> write nor maintain any code that parses the control file in dh_python.
> This script is already one of the most complex ones in d
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 12:28 +0100, Matthias Klose a écrit :
> > > I don't understand the *need* for a specific control field. I just see
> > > it as another way to implement dh_python. My opinion is that
> > > "dh_python -m 2.2" is easier to implement and looks m
Le vendredi 13 janvier 2006 à 12:28 +0100, Matthias Klose a écrit :
> > I don't understand the *need* for a specific control field. I just see
> > it as another way to implement dh_python. My opinion is that
> > "dh_python -m 2.2" is easier to implement and looks more like other dh_*
> > commands
Joe Wreschnig writes:
> On Fri, 2006-01-13 at 12:04 +0100, Matthias Klose wrote:
> > Joe Wreschnig writes:
> > > On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> > > >- modules are installed into a directory not directly in sys.path.
> > >
> > > While I understand the rationale here,
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 11:30 +0100, Matthias Klose a écrit :
> > > Having a new field in the control file diverges from how debhelper
> > > programs usually behave, so I'd like to avoid such a solution - and I
> > > don't think there's a need for it.
> >
> > I did
On Fri, 2006-01-13 at 12:04 +0100, Matthias Klose wrote:
> Joe Wreschnig writes:
> > On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> > >- modules are installed into a directory not directly in sys.path.
> >
> > While I understand the rationale here, this could be *very* confusing
>
Joe Wreschnig writes:
> On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> >- modules are installed into a directory not directly in sys.path.
>
> While I understand the rationale here, this could be *very* confusing
> for people coming to Debian from other operating systems.
People w
Le vendredi 13 janvier 2006 à 11:30 +0100, Matthias Klose a écrit :
> > Having a new field in the control file diverges from how debhelper
> > programs usually behave, so I'd like to avoid such a solution - and I
> > don't think there's a need for it.
>
> I did outline the need for it. And I see
On Fri, 2006-01-13 at 11:05 +0100, Josselin Mouette wrote:
> Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit :
> > > - Some concerns were raised by the release team, that python-support
> > > tracks it's own state instead of using the dpkg database. To keep
> > > track of usable
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit :
> > > - Some concerns were raised by the release team, that python-support
> > > tracks it's own state instead of using the dpkg database. To keep
> > > track of usable python versions, python-central u
Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit :
> > - Some concerns were raised by the release team, that python-support
> > tracks it's own state instead of using the dpkg database. To keep
> > track of usable python versions, python-central uses a field
> > Python-Version i
On Fri, 2006-01-13 at 00:33 -0600, Joe Wreschnig wrote:
> Unless I misunderstand (either or or python-support) it does,
Should be ^- "either you or python-support"
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> After a long silence (and some work on "unrelated" C++ transitions ;),
> an update to the python packaging infrastructure.
Thank you. I've snipped stuff I agree with, or don't have an opinion on
yet.
>-
Hi,
I should probably check in to this discussion, since I'm the current
(inactive) maintainer of jython -- I put it up for adoption several
months ago since I don't have so much time these days and I no longer
have much involvement with either java or jython.
A couple of notes:
- I'll probably
> It should be practical to create Java templates for PyPy to use in the
> backend to produce a python implementation that executes in a JVM.
There is one snag to "Java" templates -- since Java has no goto, good
implementations of generators are difficult. The templates might
have to be bytecode
> > It should be practical to create Java templates for PyPy to use in the
> > backend to produce a python implementation that executes in a JVM.
>
> I can't back it up, but I thought this was possible already, as well as
> a clisp backend. I know for certain C and LLVM work.
I'm quite sure there i
> I think it was a good idea at the time to avoid duplicating all of the
> pure-python modules in the standard library. However, given that
> Jython's development hasn't kept pace with CPython I think that
> eliminating the dependency would be a better choice now.
That would simplify the issue gre
On Thu, Jan 12, 2006 at 11:54:18AM -0500, Derrick Hudson wrote:
> | Anyhow, I hate to see Jython orphaned, perhaps down the road (after
> | the next Jython release) I'll come back to find out what it takes to
> | take over the package maintenance of Jython in Debian.
>
> I'd like to see Jython
On Thu, Jan 12, 2006 at 05:09:56PM +0100, Wouter van Heyst wrote:
[jython]
| Is there any reason it can't work with 2.4?
Yes. The most recent release (2.2a1) doesn't implement the new
language constructs introduced by CPython 2.3 and 2.4.
-D
--
If we claim we have not sinned, we make Him out
On Thu, Jan 12, 2006 at 10:52:43AM -0500, Frank Wierzbicki wrote:
| > At least jython isn't an issue anymore (orphaned, and
| > new upstream snapshots available)
| Hi Matthias,
|
| I am (recently) the primary maintainer of the (upstream) Jython
| project.
I'm glad to see someone is working on it.
On Thu, Jan 12, 2006 at 10:52:43AM -0500, Frank Wierzbicki wrote:
> > At least jython isn't an issue anymore (orphaned, and
> > new upstream snapshots available)
> Hi Matthias,
>
> I am (recently) the primary maintainer of the (upstream) Jython
> project. I'm also a big fan of Debian. The next r
> At least jython isn't an issue anymore (orphaned, and
> new upstream snapshots available)
Hi Matthias,
I am (recently) the primary maintainer of the (upstream) Jython
project. I'm also a big fan of Debian. The next release of Jython
will depend on either Python 2.2 or Python 2.3, if it gets pa
After a long silence (and some work on "unrelated" C++ transitions ;),
an update to the python packaging infrastructure.
We want to change the default python version used to the recent
python-2.4.2 release, and change it again to 2.5.0, when/if this
version is released before et
46 matches
Mail list logo
