Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 10:50 +1100, Felipe Sateler a écrit : current does not mean anything, semantically, especially for public modules/extensions. There is a set of supported versions, and that’s all. For extensions, it is the set of versions the extension has been built against, and for modules, it is the set of versions the module can work with. In neither of these cases does current mean anything. But it does mean something. Modules which build from C sources have to be built for each version it wants to support, right? Maybe current is an arbitrary, unjustified choice, but it means that C modules which only build once don't will only work with that version. You’re talking about XS-Python-Version: current. I don’t think there is any possible discussion about XB-Python-Version: current, which doesn’t mean anything at all. XS-Python-Version: = 2.x declares something useful for the packaging tools: that python versions starting from 2.x are supported. (Note that this could also be read directly from the build-depends, but well, people like adding useless fields to the source packages.) XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. In the real world, there is no need for this information. The packaging tool can detect much more reliably the versions for which the extension was built *after* they have been built (which is what python-support has always been doing). And since the maintainers don’t understand the difference between all and current (rightfully, since there isn’t any real difference), the real-world packages don’t fill this field as Matthias intended it. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Josselin Mouette wrote: XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. I'm not sure what you mean. If a module is only built for one version, then the other versions are not supported. Or by supported you mean that the module would eventually work with another python version if compiled for it? -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 22:06 +1100, Felipe Sateler a écrit : Josselin Mouette wrote: XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. I'm not sure what you mean. If a module is only built for one version, then the other versions are not supported. Or by supported you mean that the module would eventually work with another python version if compiled for it? Yes, and actually it *will* work with another Python version when it becomes the default. The fact that it is only built for the default version is a detail of the build system, and it has nothing to do with the list of supported versions. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit : I really like the idea of using the same location for both tools, please note that you'll have to change pycentral to use something like /usr/lib/pyshared (for Python extensions) where is the advantage of having a /usr/lib/pyshared? Robustness. When you have a directory of Python modules that is an autogenerated symlink farm, you need to be able to rebuild it from scratch if anything goes wrong. This brings the packaging helper to the same level of robustness as dpkg itself. I don't like python ( X.Y) dependencies, it's so... old-policy like. Not a good idea, IMHO well, just not liking is a weak argument. Having to regularly re-upload all architecture-independent packages without any gain sounds like a less weak one. As I did write above, the support for namespace packages should be implemented using diversions. It's ok to generate these by a packaging helper. Generating diversions automatically is doomed to fail. Diversions are fragile, and they should be the exception, not the rule. What do you do when more than 2 packages need the same empty __init__.py ? -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Michal Čihař wrote: Various --- There are other things which may be worth a look. - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 15:03 +0100, Bernd Zeimetz a écrit : - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. You really can’t say I’m not trying to discuss. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Felipe Sateler fsate...@gmail.com writes: Josselin Mouette wrote: XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. I'm not sure what you mean. If a module is only built for one version, then the other versions are not supported. However, the correct way to represent this is with: XS-Python-Version: 2.5 (for example). Since the meaning of current changes, you shouldn't use it for this purpose. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Hi Joss, On Dienstag, 17. Februar 2009, Josselin Mouette wrote: You really can’t say I’m not trying to discuss. I'm not sure if one cannot say this, as you nicely show in the following words that you definitly totally fail to discuss :( But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Python related changes for unstable/squeeze
On Tue, 2009-17-02 at 17:09 +0100, Holger Levsen wrote: Hi Joss, On Dienstag, 17. Februar 2009, Josselin Mouette wrote: You really can’t say I’m not trying to discuss. I'm not sure if one cannot say this, as you nicely show in the following words that you definitly totally fail to discuss :( I disagree. Joss is posting to the list. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. Joss says that Matthias has been unresponsive for years. That could be a factual statement ... I think you might give Matthias some time to respond himself before jumping in. regards, Holger -- --gh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Hey, On Tue, 2009-02-17 at 17:09 +0100, Holger Levsen wrote: But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. As someone who has been following this discussion from the beginning, I have to disagree with you. Josselin has been actively pointing technical, practical reasons to implement the solution in a way which is different to that Matthias chooses to implement. From my perspective Matthias failed to respond to that criticism, and ignored the possibility of consensus building taking advantage of the fact that he maintains the Python interpreter packages (and the fact that he is able to push things 100% his way into Ubuntu). See you, -- Gustavo Noronha k...@debian.org Debian Project -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 6:44 AM, Josselin Mouette j...@debian.org wrote: Le mardi 17 février 2009 à 15:03 +0100, Bernd Zeimetz a écrit : - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. You really can't say I'm not trying to discuss. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. But those should be resolved by discussing it on the list, coming to a consensus and then fixing it by merging the packages or starting from scratch. Josselin, it's true that if you were discussing with me in the same tone as you are with Matthias, it will not make me very happy (as many people have pointed out), but I appreciate that you discuss and reply to criticisms and that's the most important. So Matthias, please, try to come to this list and get this resolved once and for all. Failing to discuss and pushing things your way is bad. Ondrej -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 10:09 -0800, Ondrej Certik a écrit : Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. I’d be happy to hear these reasons; I’m always eager to improve python-support when there is room to. Currently I know one reason why you could consider python-central better: this is because it installs files at the same place the upstream packages do. This avoids breaking some (bad) packages’ expectations. I have two remarks about this: * The python-support README has documented for long how to work around this problem if you encounter it (remember it concerns a handful of packages). * If python-support was the only tool to write files to /usr/lib/pythonX.Y/site-packages, there would be no problem with using this directory. However there are packages using python-central and packages shipping files directly there, so it is simply not possible without losing the advantages of python-support (like, not introducing 50 RC bugs every time something is changed). Besides, I could show you several reasons why python-support is superior, and at least one why python-central is broken. Josselin, it's true that if you were discussing with me in the same tone as you are with Matthias, it will not make me very happy But I am not using this tone with you, and the reason is that you are behaving correctly. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
OoO Lors de la soirée naissante du mardi 17 février 2009, vers 17:09, Holger Levsen hol...@layer-acht.org disait : This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. IMO, this is unfortunate but it is really difficult to discuss with Matthias. Most comments are just ignored. For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474630 Matthias made a short statement about the problem and ignored the rest of the discussion. I had to switch to python-central to solve this bug. Josselin added a functionality to python-support to circumvent this limitation. Here is another example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440 Some fixes were proposed to circumvent this problem but bug was just marked as won't fix. This hits all users using easy_install (which is fairly popular among Python developers). And this bug is in Lenny. -- A TRAINED APE COULD NOT TEACH GYM A TRAINED APE COULD NOT TEACH GYM A TRAINED APE COULD NOT TEACH GYM -+- Bart Simpson on chalkboard in episode AABF15 pgpMRDQ4D5Dxa.pgp Description: PGP signature
Re: Python related changes for unstable/squeeze
[Matthias Klose, 2009-02-16]
Piotr Ożarowski schrieb:
- 2.5 is superseded by 2.6; currently there doesn't seem to be
a reason to ship 2.5 and modules for 2.5 with the next stable
release. The upstream 2.5 maintainance branch doesn't see bug
fixes anymore, only security releases will be made from this
branch.
What about a smooth upgrade path for those who use Python2.5 for their (3rd
party) applications? I think Python 2.6 should be default in Squeeze and
Python
2.42.5 in supported.
FTR: I meant 2.5 in supported and 2.4 in semi-supported (as in only
Zope related modules should be supported for this version)
always having the default version of the stable release included in the next
release would mean that Debian releases keep up with Python release, or we
would
end up shipping more than two 2.x versions. Same if 2.7 gets released in time.
what if administrators will install some local applications that will
have python2.5 hardcoded in shebang? Do you want to provide
python2.5-python2.6 symlink? I'm not sure it's a good idea. Are you
sure Python 2.6 (and all modules/extensions) are 2.5-compatible? Or do
you simply want to add an instruction in release notes what to do in
such situation (but then again: are you sure 2.6 and 2.5 are compatible?)
/usr/local/lib/pythonX.Y/site-packages will only be used if you install your
own python, and use this interpreter to call setup.py install. When using the
python (= 2.6) provided by Debian without to call setup.oy install
--install-layout=deb, the installation will go to
/usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to
/usr/lib/pythonX.Y/dist-packages.
/usr/local/lib/pythonX.Y/site-packages should definitely *not* be
symlinked to /usr/local/lib/pythonX.Y/dist-packages then (and vice versa)
I really like the idea of using the same location for both tools, please
note
that you'll have to change pycentral to use something like /usr/lib/pyshared
(for Python extensions)
where is the advantage of having a /usr/lib/pyshared?
it's one of the sacrifices you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
Once we'll agree on the paths, I will rise another problem I want to
discuss before we'll start converting packages but lets leave it for
later (note that I don't want to merge both tools, it's not possible, I
want a situation where one helper can ConflictProvide the other one -
yeah, you'll say it's not possible! You're crazy! - we'll see about
that :-)
Oh, one more thing: for now, I'm using both helper tools (to be aware of
their advantages/disadvantages and to be able to help my sponsorees -
please note that I never forced my sponsoree to use one of the helpers -
see FAQ#2 [1]), it's time however to decide which one will be my
winner - I'll decide that in next weeks (maybe months, but it
will happen sooner than later - my packages in Squeeze will use one
helper only!) and once I decide that, I will force all my sponsorees to
choose the same one (by refusing to upload package that uses the other
one)
IMNSHO
[placeholder for all those who want to make jokes about what I wrote in
next few lines - feel free to also make fun of me on #debian-python - at
least I will feel a little bit better after writing so many immodest
stuff ;]
If you care how many packages are using your tool, my preference should
matter to you as I'm the one who sponsored more Python related Debian
packages than anyone else in Debian - right now no one else has more
sponsored packages on QA page than I do (Anibal listed first on this[2]
page has less sponsored packages) and besides Sandro and Bernd, I'm the
only one who does regular sponsoring in PAPT and DPMT (which are
becoming more popular every day, there are rumors about magic way to get
a Python related package very well reviewed and really fast sponsored in
Debian even on #ubuntu-motu and people are prefering to do this via
Debian, really!) - I will also try to convince Bernd, Sandro and few
other DDs (Ana: that includes you! :) to use the same helper.
anyway, my army[3] and I can make a difference when it comes about
popconf stats. ;-P
[1] http://people.debian.org/~piotr/sponsor
[2] http://merkel.debian.org/~myon/sponsorstats/
[3] http://people.debian.org/~piotr/sponsorees.png
I don't like python ( X.Y) dependencies, it's so... old-policy like.
Not a good idea, IMHO
well, just not liking is a weak argument.
that's OLD-POLICY-LIKE, that should be enough argument, IMO ;-P
Providing
Re: Python related changes for unstable/squeeze
Le mercredi 18 février 2009 à 01:20 +0100, Piotr Ożarowski a écrit :
where is the advantage of having a /usr/lib/pyshared?
it's one of the sacrifices you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
It seems that there is one thing you got wrong here. /usr/lib/pyshared
will be for C extensions and data that varies from a Python version to
another (like /usr/lib/python-support/$package currently). It is not the
place where the symlinks and byte-compiled files will land after running
the script.
For this last thing, I initially thought of
using /usr/lib/pythonX.Y/python-support, but I guess the rtinstall
script of python-central will mess with that directory, so in the end
I’d prefer to find something else. Maybe /usr/lib/pymodules/pythonX.Y ?
Please also note that pysupport has a nice feature (that IMO should be
disabled by default, though (I'll file a bug soon), of byte compiling
modules for officially not supported Python versions (if installed *and*
maintainer claims it's compatible with that version) - this helps f.e.
if one installed python2.6 right now (or python2.5 in Etch)
Actually, it’s just that the supported list in python-support is
maintained separately from that of python-defaults. The reason is that
the pyversions script cannot be reliably used from maintainer scripts.
See #396840 for part of the explanation.
--
.''`. Debian 5.0 Lenny has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`-me that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
[Josselin Mouette, 2009-02-18]
Le mercredi 18 février 2009 à 01:20 +0100, Piotr Ożarowski a écrit :
where is the advantage of having a /usr/lib/pyshared?
it's one of the sacrifices you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
It seems that there is one thing you got wrong here. /usr/lib/pyshared
will be for C extensions and data that varies from a Python version to
another (like /usr/lib/python-support/$package currently). It is not the
place where the symlinks and byte-compiled files will land after running
the script.
that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
/usr/share/py{,3}shared but for Python extensions, sorry if I sounded
differently
Actually, it’s just that the supported list in python-support is
maintained separately from that of python-defaults. The reason is that
the pyversions script cannot be reliably used from maintainer scripts.
See #396840 for part of the explanation.
oh, w wishlist bug then maybe (to be able to add local version, like
python2.6)
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpkTVUJuUZa3.pgp
Description: PGP signature
Re: Python related changes for unstable/squeeze
Le mercredi 18 février 2009 à 02:23 +0100, Piotr Ożarowski a écrit :
that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
/usr/share/py{,3}shared but for Python extensions, sorry if I sounded
differently
OK, I misunderstood you then :)
Any comment on the module installation directory? Is /usr/lib/pymodules
fine for you?
--
.''`. Debian 5.0 Lenny has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`-me that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 10:34 AM, Josselin Mouette j...@debian.org wrote: Le mardi 17 février 2009 à 10:09 -0800, Ondrej Certik a écrit : Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. I'd be happy to hear these reasons; I'm always eager to improve python-support when there is room to. Currently I know one reason why you could consider python-central better: this is because it installs files at the same place the upstream packages do. This avoids breaking some (bad) packages' expectations. I have two remarks about this: * The python-support README has documented for long how to work around this problem if you encounter it (remember it concerns a handful of packages). * If python-support was the only tool to write files to /usr/lib/pythonX.Y/site-packages, there would be no problem with using this directory. However there are packages using python-central and packages shipping files directly there, so it is simply not possible without losing the advantages of python-support (like, not introducing 50 RC bugs every time something is changed). Besides, I could show you several reasons why python-support is superior, and at least one why python-central is broken. I forgot already what those reasons were, Matthias told me in Prague and they seemed reasonable to me. In fact, we were having a similar flame discussion about python-central and python-support just before the summit on this list and the result of which was (to me, as a bystander) that python-support is clearly superior, so I asked Matthias about it, and he provided some good arguments for python-central. But these arguments should be put on the list and things should get discussed and fixed. Anyway, I think now it's Matthias' turn to come forward and also do a few steps to get this discussed and eventually fixed. Ondrej -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
[Piotr Ożarowski, 2009-02-18]
that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
/usr/share/py{,3}shared but for Python extensions, sorry if I sounded
differently
and by that I mean /usr/lib/py{3,}shared/python2.5,
/usr/lib/py{3,}shared/python2.6 and so on (including .py files that are
not suitable for /usr/share/py{3,}shared)
/me really goes to bed
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgp6J6MzkDwaR.pgp
Description: PGP signature
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 6:03 AM, Piotr Ożarowski pi...@debian.org wrote: [Matthias Klose, 2009-02-16] Besides the normal pending update of the python version for the unstable distribution, there will be more changes around python packaging, including the introduction of python-3.x and addressing some packaging issues. How do other distributions deal with these issues? Will the need for special per-tool directories ever be obsoleted by upstream? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Dne Wed, 18 Feb 2009 13:16:09 +0900 Paul Wise p...@debian.org napsal(a): On Tue, Feb 17, 2009 at 6:03 AM, Piotr Ożarowski pi...@debian.org wrote: [Matthias Klose, 2009-02-16] Besides the normal pending update of the python version for the unstable distribution, there will be more changes around python packaging, including the introduction of python-3.x and addressing some packaging issues. How do other distributions deal with these issues? Will the need for special per-tool directories ever be obsoleted by upstream? I'm not sure if there is some other distribution, which support more Python versions at similar level as Debian. SUSE and Fedora definitely support only one Python version (with Zope usually being the exception with minimal subset of modules). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Python related changes for unstable/squeeze
Besides the normal pending update of the python version for the unstable distribution, there will be more changes around python packaging, including the introduction of python-3.x and addressing some packaging issues. Python versions --- - 2.4 is still used by zope-2.x and depending packages like plone. There was a SoC project which intended to update zope-2.x to use a newer python version, but afaik this didn't reach a stable state yet. It doesn't make sense to provide a full set of third party python modules and extensions for 2.4. If it is forseeable that zope-2.x still requires 2.4 when the freeze for the next Debian release approaches, maybe package only 2.4 modules for zope-2.x's and plone's dependencies. An alternative might be not to distribute zope-2.x and plone with the next stable release. - 2.5 is superseded by 2.6; currently there doesn't seem to be a reason to ship 2.5 and modules for 2.5 with the next stable release. The upstream 2.5 maintainance branch doesn't see bug fixes anymore, only security releases will be made from this branch. - 2.6 is the current stable release which should enter unstable soon and become the default after extension packages supporting more than one python version are built and migrated to testing. - I do not want to speculate about a 2.7 release and the upstream version freeze for the next Debian release. If the 2.7 release is well ahead of the Debian freeze, then there should be no problem to include it. - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. Packaging for Python 3.x Python 3.x is not upward compatible to 2.x and requires changes to the sources. Almost no file can be used unmodified. A large part of the changes can be done automatically with the help of the 2to3 utility. Porting resources can be found at - http://docs.python.org/3.0/whatsnew/3.0.html#porting-to-python-3-0 - http://docs.python.org/3.0/howto/cporting.html#cporting-howto - http://docs.python.org/3.0/library/2to3.html Upstream does expect Python-2.x to stay around for a while; Python-3.x will need some time until extensions and modules are ported. For this reason I do plan to have both Python-2.x and Python-3.x in the next stable Debian release. Some third party modules and extensions may be released in a form where the code for 3.x can be auto-generated from the 2.x code with the 2to3 utility, some upstreams may decide to stop 2.x support with one version and provide 3.x support with another version. Debian has to support both approaches. The currently used packaging methods only allow packaging of one version for all Python version (installing in a shared area and providing this version for each Python version). Binary packages will double in size when providing both 2.x and 3.x compatible code, so it does make sense to provide separate binary packages for 2.x and 3.x. These new packages should be prefixed with `python3-' instead of `python-'. It's up to the package maintainer if these packages are built from one or two source packages. There will be a `python3' package and similiar packages built out of a python3-defaults, which will provide the `python3' binary. Local installation path --- When installing Python modules using distutils, the resulting files end up in the same location wether they are installed by a Debian package, or by a local user or administrator, unless the installation path is overwritten on the command line. Compare this with most software based on autoconf, where an explicit prefix has to be provided for the packaging, while the default install installs into /usr/local. For new Python versions packaged in Debian this will change so that an installation into /usr (not /usr/local) requires an extra option to distutils install command (--install-layout=deb). To avoid breaking the packaging of existing code the distutils install command for 2.4 and 2.5 will just accept this option and ignore it. For the majority of packages we won't see changes in the packaging, provided that the python packaging helpers can find the files in the right location and move it to the expected target path. A second issue raised by developers was the clash of modules and extensions installed by a local python installation (with default prefix /usr/local) with the modules provided by Debian packages (/usr/local/lib/pythonX.Y/site-packages shared by the patched system python and the locally installed python. To avoid this clash the directory `site-packages' should be renamed to `dist-packages' in both locations: - /usr/lib/pythonX.Y/dist-packages (installation location for code packaged for Debian) - /usr/local/lib/pythonX.Y/dist-packages (installation
Re: Python related changes for unstable/squeeze
[debian-pyt...@l.d.o added to To and Reply-To, citing whole mail for those who don't read -devel, me included ] First of all: thanks Matthias for your work on Python package(s) [Matthias Klose, 2009-02-16] Besides the normal pending update of the python version for the unstable distribution, there will be more changes around python packaging, including the introduction of python-3.x and addressing some packaging issues. Python versions --- - 2.4 is still used by zope-2.x and depending packages like plone. There was a SoC project which intended to update zope-2.x to use a newer python version, but afaik this didn't reach a stable state yet. It doesn't make sense to provide a full set of third party python modules and extensions for 2.4. If it is forseeable that zope-2.x still requires 2.4 when the freeze for the next Debian release approaches, maybe package only 2.4 modules for zope-2.x's and plone's dependencies. An alternative might be not to distribute zope-2.x and plone with the next stable release. - 2.5 is superseded by 2.6; currently there doesn't seem to be a reason to ship 2.5 and modules for 2.5 with the next stable release. The upstream 2.5 maintainance branch doesn't see bug fixes anymore, only security releases will be made from this branch. What about a smooth upgrade path for those who use Python2.5 for their (3rd party) applications? I think Python 2.6 should be default in Squeeze and Python 2.42.5 in supported. - 2.6 is the current stable release which should enter unstable soon and become the default after extension packages supporting more than one python version are built and migrated to testing. - I do not want to speculate about a 2.7 release and the upstream version freeze for the next Debian release. If the 2.7 release is well ahead of the Debian freeze, then there should be no problem to include it. - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. Packaging for Python 3.x Python 3.x is not upward compatible to 2.x and requires changes to the sources. Almost no file can be used unmodified. A large part of the changes can be done automatically with the help of the 2to3 utility. Porting resources can be found at - http://docs.python.org/3.0/whatsnew/3.0.html#porting-to-python-3-0 - http://docs.python.org/3.0/howto/cporting.html#cporting-howto - http://docs.python.org/3.0/library/2to3.html Upstream does expect Python-2.x to stay around for a while; Python-3.x will need some time until extensions and modules are ported. For this reason I do plan to have both Python-2.x and Python-3.x in the next stable Debian release. Some third party modules and extensions may be released in a form where the code for 3.x can be auto-generated from the 2.x code with the 2to3 utility, some upstreams may decide to stop 2.x support with one version and provide 3.x support with another version. Debian has to support both approaches. The currently used packaging methods only allow packaging of one version for all Python version (installing in a shared area and providing this version for each Python version). Binary packages will double in size when providing both 2.x and 3.x compatible code, so it does make sense to provide separate binary packages for 2.x and 3.x. These new packages should be prefixed with `python3-' instead of `python-'. It's up to the package maintainer if these packages are built from one or two source packages. There will be a `python3' package and similiar packages built out of a python3-defaults, which will provide the `python3' binary. Local installation path --- When installing Python modules using distutils, the resulting files end up in the same location wether they are installed by a Debian package, or by a local user or administrator, unless the installation path is overwritten on the command line. Compare this with most software based on autoconf, where an explicit prefix has to be provided for the packaging, while the default install installs into /usr/local. For new Python versions packaged in Debian this will change so that an installation into /usr (not /usr/local) requires an extra option to distutils install command (--install-layout=deb). To avoid breaking the packaging of existing code the distutils install command for 2.4 and 2.5 will just accept this option and ignore it. For the majority of packages we won't see changes in the packaging, provided that the python packaging helpers can find the files in the right location and move it to the expected target path. A second issue raised by developers was the clash of modules and extensions
Re: Python related changes for unstable/squeeze
Le lundi 16 février 2009 à 20:33 +0100, Matthias Klose a écrit :
Besides the normal pending update of the python version for the
unstable distribution, there will be more changes around python
packaging, including the introduction of python-3.x and addressing
some packaging issues.
It’s nice to have this status update, but why wasn’t this discussed on
debian-python first?
There will be a `python3' package and similiar packages built out of a
python3-defaults, which will provide the `python3' binary.
Good. That’s the only sane way to go.
The use of a common location was proposed in 2006, but didn't get any
feedback at this time. Last summer I did choose a name for this
location, and a large part of packages already install into this
location `/usr/share/pyshared'. For code shared between Python-3.x
installations I propose to use `/usr/share/py3shared'.
Using the /usr/share/py*shared common location in python-support is
technically feasible, but it’s opening the door to letting
python-central break other packages than those using it, so this is
probably not going to happen.
The choice of packaging helper should not add additional constraints
on upstream software. To avoid these problems in the future, exactly
one location for public python modules shold be used.
I have already explained why it is a bad idea to ship the installed .so
files and the symlinks directly in the /usr/lib/python2.X/site-packages
directories. I am certainly not going to change python-support for this
brokenness.
- Not removing symlinked files and not removing byte-compiled files
during upgrades. This only works reliable if the new version
does neither remove nor add files, or else an inconsistent set of
files in a package may be imported during an upgrade.
And that’s also what happens when files are updated by dpkg. At a given
time, there may be an inconsistent set of files installed on the system.
There is still the issue of handling name space packages based on
setuptools. Ideally existing techniques like diversions should be used
for this, even if it looks loke overkill to divert the same empty
__init__.py file.
Creating empty __init__.py files as needed is the role of the packaging
helper. This is what python-support already does in lenny.
- The current policy advises packages to byte-compile only the
files which a package owns itself. This is not done by several
packages, with the result that an upgrade caused by a byte-
compilation error may be attributed to the wrong package (makes
the upgrade of an otherwise fine package fail).
A problem solved in python-support by using triggers and not failing for
a byte-compilation error.
- The removal of a python version will cause the need for massive
rebuilds. because many python extensions currently have
dependencies of the form pythonX.Y-foo. There is nothing what
can be done now for the upcoming removal, but those dependencies
should not be there by default. This is 2.4 of the python policy,
but many packages tend to ignore that.
There is a very good reason to add these dependencies. Ignoring the
requests to update the policy accordingly is not going to make the
problem disappear magically. Packages must not have a Provides:
${python:Provides} field if these dependencies are not present.
Otherwise, packages depending on this incorrectly provided version are
going to fail miserably.
Instead of this nonsense, the move to Python 3 sounds like the perfect
time to finally phase out python-central. Given the flaws in its design
and the lack of correct maintenance, there have already been several
reports of broken upgrades from etch to lenny that have been directly
caused by python-central. If you can’t fix it, please just drop it.
If you really want to improve the overall situation, maybe it is also
the time to think of fixing the interpreter for good instead of adding
layers of symbolic links farms. For example, if it was able to merge
several directory hierarchies in a single module hierarchy - like perl
had been doing in Debian for years before python-support was even
written - the overall needs for Python packaging would be greatly
simplified.
--
.''`. Debian 5.0 Lenny has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and
`-told that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Piotr Oz.arowski schrieb: - 2.5 is superseded by 2.6; currently there doesn't seem to be a reason to ship 2.5 and modules for 2.5 with the next stable release. The upstream 2.5 maintainance branch doesn't see bug fixes anymore, only security releases will be made from this branch. What about a smooth upgrade path for those who use Python2.5 for their (3rd party) applications? I think Python 2.6 should be default in Squeeze and Python 2.42.5 in supported. always having the default version of the stable release included in the next release would mean that Debian releases keep up with Python release, or we would end up shipping more than two 2.x versions. Same if 2.7 gets released in time. The path /usr/lib/pythonX.Y/site-packages is not found on sys.path anymore. is local/ missing in this path or do you want to simply rename site-packages into dist-packages? /usr/local/lib/pythonX.Y/site-packages isn't found in sys.path as well. About the name: Discussed this with Barry Warsaw and Martin v. Loewis, and we came to the conclusion that using the same directory name for both locations would be the most consistent way. This change should make the request to conditionalize the inclusion of /usr/local/lib/pythonX.Y/site-packages into sys.path obsolete. if I understand this correctly, local installations (including ez_install ones) will use /usr/local/.../site-packages and the ones used by administrators (who know about --install-layout=deb) /usr/local/.../dict-packages, and the site-packages will not be in default sys.path, right? No, /usr/local/lib/pythonX.Y/site-packages will only be used if you install your own python, and use this interpreter to call setup.py install. When using the python (= 2.6) provided by Debian without to call setup.oy install --install-layout=deb, the installation will go to /usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to /usr/lib/pythonX.Y/dist-packages. If yes, then although I love the idea of solving the `sudo easy-install MyModule` really annoying issue (last time I raised it here[1], see also Christoph's Why you should not use easy_install carelessly on Debian[2]), what's a purpose of having local site-packages if installing there will have no effect. Or do you want to keep it for local *Python* interpreter installations? It is not kept, it is the standard site-packages for local *Python* interpreter installations. I really like the idea of using the same location for both tools, please note that you'll have to change pycentral to use something like /usr/lib/pyshared (for Python extensions) where is the advantage of having a /usr/lib/pyshared? yes, that's a problem, but I think we should do it step by step, first: all packages should ship .py and .so files in the same directories (so that dpkg can handle conflicts again), then we'll think about using common entry in sys.path (and/or merging helper tools or making it possible to choose one of them to do all the stuff) I can agree on later, if it does mean for squeeze. The disadvantage of this approach is the limitation to a specific set of python versions (the package will have a dependency of the form python ( X.Y), which we already have for architecture dependent packages containing extensions. This would add this kind of dependency to all architecture independent python-* modules and then requires an upload of these packages for each python transition as well. Afaics this would not affect a transition or a set of transitions to testing, because no new dependencies on new versions of shared libraries are introduced during these uploads. This approach certainly has an impact on the ftp archive and its mirrors, but I can't say if this would be an issue or not. I don't like python ( X.Y) dependencies, it's so... old-policy like. Not a good idea, IMHO well, just not liking is a weak argument. - The removal of a python version will cause the need for massive rebuilds. because many python extensions currently have dependencies of the form pythonX.Y-foo. There is nothing what can be done now for the upcoming removal, but those dependencies should not be there by default. This is 2.4 of the python policy, but many packages tend to ignore that. python-support supports namespace packages and it does it good. I didn't want it to be enabled by default but since Joss provided a way to disable it (see #459468) I think it's OK. python-central should implement the same behaviour, IMHO As I did write above, the support for namespace packages should be implemented using diversions. It's ok to generate these by a packaging helper. Just one more issue: what about current issue? Although I protested when others wanted to remove it, now I agree it's useless. All packages that depend on it (Python applications mostly) should use private directories and thus not pollute the global namespace (we
Re: Python related changes for unstable/squeeze
Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit : current is also useful to only provide a public module for just the default version. I'm unsure what you mean with when talking about the above mentioned issue Is it a joke? If you don’t know what this is about, why are you even talking about python packaging? Were you even reading the discussions on the Python policy when there have been some? current does not mean anything, semantically, especially for public modules/extensions. There is a set of supported versions, and that’s all. For extensions, it is the set of versions the extension has been built against, and for modules, it is the set of versions the module can work with. In neither of these cases does current mean anything. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Hi Matthias, thanks for all the work you do. I have one question: - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. It would really help if Debian had python3.0, becuase it would help me, as upstream, to port my software. Currently I have to compile python3.0 from the ubuntu source package. If ubuntu can have it, why not Debian? Ondrej -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Ondrej Certik schrieb: Hi Matthias, thanks for all the work you do. I have one question: - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. It would really help if Debian had python3.0, becuase it would help me, as upstream, to port my software. Currently I have to compile python3.0 from the ubuntu source package. If ubuntu can have it, why not Debian? I will provide packages on people.debian.org, which should help for the upstream work. python-3.0 is very short lived and I do want to avoid an unnecessary transition. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Mon, Feb 16, 2009 at 2:15 PM, Matthias Klose d...@debian.org wrote: Ondrej Certik schrieb: Hi Matthias, thanks for all the work you do. I have one question: - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. It would really help if Debian had python3.0, becuase it would help me, as upstream, to port my software. Currently I have to compile python3.0 from the ubuntu source package. If ubuntu can have it, why not Debian? I will provide packages on people.debian.org, which should help for the upstream work. python-3.0 is very short lived and I do want to avoid an unnecessary transition. Ok, that makes sense. Thanks! Ondrej -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Hi [I agree that this should have have been sent also to debian-python] Dne Mon, 16 Feb 2009 20:33:48 +0100 Matthias Klose d...@cs.tu-berlin.de napsal(a): - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. I would be great to have also 3.0.x (even in experimental and with no third party modules at all). At least for us who also wear an upstream hat sometimes. This change should make the request to conditionalize the inclusion of /usr/local/lib/pythonX.Y/site-packages into sys.path obsolete. If needed we can provide a symlink /usr/lib/pythonX.Y/site-packages pointing to dist-packages. Does this mean that /usr/local/lib/pythonX.Y/site-packages is meant for custom installation of Python in /usr/local/, while /usr/local/lib/pythonX.Y/dist-packages for packages for Python shipped in Debian? That looks like too complicated to me and it will lead to mistakes, when single directory (/usr/local/lib/pythonX.Y) is supposed to be partly used by two different Python installations. Various --- There are other things which may be worth a look. - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Python related changes for unstable/squeeze
Various --- There are other things which may be worth a look. - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. I strongly support this. I also use both in my packages and I would prefer if there was just one way. I don't mind which. Ondrej -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Matthias Klose d...@cs.tu-berlin.de writes: Local installation path --- […] - /usr/lib/pythonX.Y/dist-packages (installation location for code packaged for Debian) - /usr/local/lib/pythonX.Y/dist-packages (installation location for locally installed code using distutils install without options). The path /usr/lib/pythonX.Y/site-packages is not found on sys.path anymore. About the name: Discussed this with Barry Warsaw and Martin v. Loewis, and we came to the conclusion that using the same directory name for both locations would be the most consistent way. I like this change; it's a good step toward making Python distribution work on Debian more like everything else on Debian. Congratulations for all involved in making this happen, and thank you for discussing (and getting consensus) with the Python core developers too. -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Josselin Mouette wrote: Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit : current is also useful to only provide a public module for just the default version. I'm unsure what you mean with when talking about the above mentioned issue Is it a joke? If you don’t know what this is about, why are you even talking about python packaging? Were you even reading the discussions on the Python policy when there have been some? current does not mean anything, semantically, especially for public modules/extensions. There is a set of supported versions, and that’s all. For extensions, it is the set of versions the extension has been built against, and for modules, it is the set of versions the module can work with. In neither of these cases does current mean anything. But it does mean something. Modules which build from C sources have to be built for each version it wants to support, right? Maybe current is an arbitrary, unjustified choice, but it means that C modules which only build once don't will only work with that version. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
