hon transition.
Packages with private extensions still cannot make use of anything but
"current" to take real advantage of the new policy (things like ">= 2.3"
are a lie because they can still only support one version at a time). If
you get rid of it, they are back to the crappy
unstated and deferring to an external helper program, but that
> is another thread
Until dh_python's behavior stops changing every other week this is an
act of futility. I tried to emphasize this previously, but it seems to
be a lost cause. Packaging Python programs is going to require debhelper
or CDBS, as well as pysupport or pycentral, for the forseeable future. I
realize this will make you very unhappy, but it's just something you
will have to deal with for now.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
In other words, it will load the 2.3 extension even when it's running on
Python 2.4. That's bad.
Why hasn't this been updated to support multiple versions of Python?
That's what public extensions should do now.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Tue, 2006-07-25 at 14:27 +0200, Josselin Mouette wrote:
> Le lundi 24 juillet 2006 à 23:18 -0500, Joe Wreschnig a écrit :
> > (Or, finally announce that Python 2.4 is plain too late for etch. Then
> > people can have as long as they want to debate over this crap, and
> >
ake any more "cosmetic" feature/change
requests until after the transition actually happens.
(Or, finally announce that Python 2.4 is plain too late for etch. Then
people can have as long as they want to debate over this crap, and
Python developers can just give up hope.)
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Wed, 2006-06-28 at 20:09 +0200, Josselin Mouette wrote:
> Le mardi 27 juin 2006 à 19:10 -0500, Joe Wreschnig a écrit :
> > > How it's that different than patch the source packages to
> > > s/python2.4/python/ as we do actually in some cases or replacing to
> &g
> (...)
>
> How it's that different than patch the source packages to
> s/python2.4/python/ as we do actually in some cases or replacing to
> python2.3 when it isn't 2.4 compatible code?
distutils rewrites scripts at installation time. Patching the source
package
ny
locally-installed package to switch to dpkg's version.
Unless there's a good reason for this behavior, I think this is a grave
bug for pycentral, since no other part of the packaging system creates
errors in this situation.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Descri
#x27;s changing every other
hour).
The package is not at all complicated. I don't expect it to ever need
changes if Python policy stablizes, since it's a single .py file with a
distutils script.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Tue, 2006-06-20 at 07:27 +0200, Andreas Barth wrote:
> * Joe Wreschnig ([EMAIL PROTECTED]) [060620 07:14]:
> > On Tue, 2006-06-20 at 06:49 +0200, Andreas Barth wrote:
> > > * Raphael Hertzog ([EMAIL PROTECTED]) [060620 01:35]:
> > > > On Mon, 19 J
acy). To get rid of one while adding
the other is dumb.
Pierre Habouzit, the developer who suggested X-PSV, has told me in
private that he agrees with my criticism, and is surprised that Raphael
went ahead with using it before any discussion on the matter (besides a
brief criticism from me, on the list, about why his intended purpose
would be pointless).
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
e let me know.
The Python policy SGML document is available at
http://people.debian.org/~piman/python-policy, I suggest someone with
more patience adopts it and finds a new canonical home for it. Please
give the first bullet point in the "Upgrade Procedure" checklist careful
thought before you
t another
one in your previous mail?
No thanks, I'm done with this stupidity.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
port to
> > stable, is enough of a pain to make it reasonable to ask what benefit
> > these users will get in return.
Supporting just one version, the current one, is fine. However, you do
need to migrate the package to use pycentral, since dh_python alone will
no longer manage the by
Version is bumped also,
> but it's not distinctive of python and not python related packages.
This isn't really helpful now. Many packages have been uploaded already,
without this field.
Anything conforming to the new policy has XS-Python-Version. That seems
to be enough to detect that it's been migrated.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
ust
haven't gotten around to yet).
So far, it's not been very helpful.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
ant to use pyxpcom with modules that aren't
> available with the current python ?
But a user couldn't install more than one such module at a time, since
the packages are mutually exclusive. It seems far better to me to just
force everyone to use one version and avoid the issue.
Or, fix pyxpcom, which sounds horribly broken.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Tue, 2006-06-13 at 01:14 +0200, Matthias Klose wrote:
> Joe Wreschnig writes:
> > I have updated the Python policy document based on the discussions on
> > the list. An updated DebianDoc (and HTML and text files) can be found at
> > http://people.debian.org/~piman/python
hemselves to get the available list
of Python versions, and run each one on setup.py (see
[EMAIL PROTECTED] for an example). Pure Python modules
using python-support won't need to.
> Hmm, I guess it's called by dh_python, and debhelper doesn't depend on
> python at all.
Yes
once this close to the freeze.
Only a dozen or so packages bother with /usr/lib/site-python, and almost
all of them are buggy for placing unstable APIs in a public module
directory anyway. Note that it's *not* being removed from sys.path
(yet), it's just being deprecated. We depreca
hout using debhelper;
I suspect those are now almost impossible to make sanely.
Probably:
1) The "Upgrade Procedure" section needs work (from RMs)
2) I have some details wrong
3) My explanations could be clearer (but I feel it's an
improvement over the old structure)
> Joe, will this be documented in the new Python policy?
As I said, I do want to keep the code examples. But until something is
actually merged into debhelper I don't think it will help to document it
in policy.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Fri, 2006-06-09 at 08:32 +0200, Raphael Hertzog wrote:
> On Mon, 05 Jun 2006, Raphael Hertzog wrote:
> > On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> > > policy is. So here's *my* attempt at summarizing the BoF, based on your
> > > first mail and responses, a
mmands with dh_ if you do this. Call
it deb_pysupport/deb_pycentral or something, and likewise please don't
mess with #DEBHELPER#. Stomping all over the namespace because you were
rejected from the package per se seems to miss Joey's point.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Please don't Cc me. I am on the list.
On Thu, 2006-06-08 at 23:05 +0200, Matthias Klose wrote:
> Joe Wreschnig writes:
> > On Thu, 2006-06-08 at 09:33 +0200, Raphael Hertzog wrote:
> > > [ Please don't keep the BTS cced if you reply unless you want to express a
>
of a system that's now in common
use (python-support).
Since then, a new policy -- from Matthias -- has made that patch
invalid. It's unfair (at best) to demand someone write a replacement
Real Soon Now, when this *is* a replacement, and not soon at all, and
pycentral got a he
mplified because
everything would be in the same binary package (so it wouldn't be
limited by debian/control).
New tools aren't needed to make binNMUs easier, though they can do that
too. A few policy changes (mostly what I outlined in my last mail) would
be enough to do that with existi
On Sun, 2006-06-04 at 23:05 +0200, Raphael Hertzog wrote:
> On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> > On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote:
> > > Hello,
> > >
> > > now you know a bit better the policy (or at least the generic idea
ortant part. It's here, and we're using it.
python-central has "right arond the corner" for months. Many modules are
already using -support, and it integrates very easily with any project
using distutils. With proper debhelper integration it would be even
simpler.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Fri, 2006-06-02 at 14:43 -0700, Steve Langasek wrote:
> On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote:
> > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> > > * the dependencies (hopefully created automatically by dh_python) will
> > >
f tools to do exactly what we did before.
Given that we still have a ton of (virtual) python2.x-foo packages under
this policy, and any Python package would still need to be rebuilt
during a transition, I don't see how this policy does anything useful.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
y not be the best time to start it, but this needs to start
very soon. The etch release plan starts calling for freezes by July, and
I know you're going to need time working on other parts of the toolchain
before then.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Sat, 2006-02-04 at 10:13 +0900, Sanghyeon Seo wrote:
> But in case of feedparser and web.py, aren't they just a single file?
> I can't blame upstream for not interested in setup.py. I'm not sure
> what Joe Wreschnig means when he says it's "unmanagable".
gives the
> order of magnitude.
This sounds far too high. Are you including packages with private .py
files that are not modules? This is common, and one of the reasons I
said it was hard to gauge.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
in isn't an exhaustive list of Python packaging irregularities
though, so I'm going to guess there's more. It's hard to find these
automatically because there's no consistent way they're packaged.
amaroK, for example, doesn't byte-compile the modules at all.
--
Joe Wre
On Wed, 2006-02-01 at 16:16 +0100, Josselin Mouette wrote:
> Le mardi 31 janvier 2006 à 16:08 -0600, Joe Wreschnig a écrit :
> > The immediate problem: PyGTK encourages other Python modules to use its
> > code generator and GObject wrappers. Between 2.6 and 2.8 the ABI chan
On Wed, 2006-02-01 at 16:16 +0100, Josselin Mouette wrote:
> Le mardi 31 janvier 2006 à 16:08 -0600, Joe Wreschnig a écrit :
> > The immediate problem: PyGTK encourages other Python modules to use its
> > code generator and GObject wrappers. Between 2.6 and 2.8 the ABI chan
might
have a dumb mistake in it. My Perl is also rusty.
* See the note on package aliases in the policy update.
--
Joe Wreschnig <[EMAIL PROTECTED]>
--- /usr/bin/dh_python 2006-01-16 16:36:44.0 -0600
+++ dh_python 2006-01-31 16:03:41.0 -0600
@@ -18,7 +18,11 @@
dh_python is a
not "I'd like to write
scripts in X" but "There is this large body of people writing scripts in
X, and it'd be nice if we could work with them."
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
the motions without actually changing our Python packaging or
upgrading the version, so we just got all of Python as Essential. No one
wanted that.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Thu, 2006-01-19 at 09:31 +, Colin Watson wrote:
> On Wed, Jan 18, 2006 at 11:36:13PM -0600, Joe Wreschnig wrote:
> > On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote:
> > > Some reasons:
> > >
> > > * compatability with Ubuntu -- so that packa
On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote:
> debian-python Cc'ed
>
> On Wed, Jan 18, 2006 at 07:02:32PM -0600, Joe Wreschnig wrote:
> > > This is something that Python upstream explicitly does not want; the only
> > > reason for creating python
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 h
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,
On Fri, 2005-12-30 at 12:33 -0600, Joe Wreschnig wrote:
> 1. Stop compiling .pyo files, entirely (I'm hoping for little argument
> on this).
>
> Rationale: .pyo files are a joke. They aren't optimized in any
> meaningful sense, they just have asserts removed. Examples
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 databas
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
r of supporting an infrastructure handling extensions and
> modules outside the default sys.path well, which ever this
> implementation will look like.
It seems to me that it would be easier to extend python-support, which
is already in the archive (and as far as I can tell, working basically
as intended) to use the proposed control field.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Mon, 2006-01-02 at 18:31 +0100, "Martin v. Löwis" wrote:
> Joe Wreschnig wrote:
> > 1. Stop compiling .pyo files, entirely (I'm hoping for little
> > argument on this).
>
> I agree.
>
> > How?: compileall.py:57, -cfi
hat takes care of the byte-compilation. This is the solution
> I've been working on the last weeks, but it isn't ready yet.
In my opinion, 1 is the better course. As you said, 2 is a lot of work.
Since I'm not convinced bytecode is desirable in the general case, I
don't think it's worth maintaining such a python-support rather than
just not using bytecode.
I would be interested in seeing what you have so far.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
t current policy is appropriate.
Well, "appropriate" might not be the right idea -- "the best I can think
of for now" would be better. As long as Python changes its
library/soname each version, there's not much we can do about this.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
if we keep .pyc files, I think loosening this requirement is a good
idea. Programs will still run perfectly fine with mis-versioned .pyc
files; the worst we'll see is some slightly longer startup times.
How?: Strike the third paragraph from 3.1.1. This would also negate the
fifth paragraph,
wrote:
> > Not correct. You suppress any other flags which are set in
> > /usr/lib/python2.x/config/Makefile
>
> No, it doesn't. CFLAGS is *added* to flags set in Makefile.
> Check Python 2.3's distutils/sysconfig.py near line 168.
Awesome, thanks!
--
Joe Wreschnig
On Fri, 2005-09-16 at 21:00 +0200, Matthias Klose wrote:
> Joe Wreschnig writes:
> > I guess I should ask here, too. Does anyone know why Python is compiled
> > with -O3 rather than -O2? Also, does anyone know the best way to
> > override distutils on a per-arch basis to chan
On Fri, 2005-09-16 at 00:37 -0500, Joe Wreschnig wrote:
> On Thu, 2005-09-15 at 19:47 -0700, Steve Langasek wrote:
> > If you have a patch that fixes the ICEs on m68k, by all means please forward
> > it to the BTS.
> >
> > But a larger question is, why are so many pa
ode objects. They're
automatically recoded when you try to print them (based on the same
function lgettext uses, locale.getpreferredencoding()). As Steve said,
unicode objects are basically like str objects, so code changes should
be minimal. I'll take a look at Linda/Lintian soon to see what needs to
be done, but I suspect it'll be trivial.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
o localize a module since then you
don't want to screw with __builtin__; you should use a local _
assignment instead (http://www.python.org/doc/current/lib/node329.html).
It's basically what you wrote.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
permail/python-dev/2005-February/051465.html
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Sat, 2003-08-23 at 23:54, Donovan Baarda wrote:
> On Sun, 2003-08-24 at 09:38, Joe Wreschnig wrote:
> [...]
> > pydance comes with a number of "modules", which are actually its core
> > source code split into managable files. It installs these to
> > /usr/sha
in pydance's case (6800 lines, 27
files) is unmeasurable, it takes up more space, and means backporting
the package becomes necessary for testing users.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
x27;s output indicates that the vast majority are ready, though.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
had succeeded, it would've tried to convert several other arguments to
integers, which also would've failed.
Unfortunately, my Tk-fu is nonexistent. Can anyone pinpoint where this
bug is (uligo, Tkinter, Tk 8.4?) I think it's an incompatibility between
Tkinter and Tk 8.4, but I'm not sure.
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
62 matches
Mail list logo
