Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Python related changes for unstable/squeeze (http://www.linux-archive.org/debian-development/246774-python-related-changes-unstable-squeeze.html)

Michal Čihař 02-16-2009 09:27 PM

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 <doko@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

Ondrej Certik 02-16-2009 09:34 PM

Python related changes for unstable/squeeze
 
On Mon, Feb 16, 2009 at 2:15 PM, Matthias Klose <doko@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ondrej Certik 02-16-2009 10:09 PM

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ben Finney 02-16-2009 10:24 PM

Python related changes for unstable/squeeze
 
Matthias Klose <doko@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Felipe Sateler 02-16-2009 10:50 PM

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Josselin Mouette 02-17-2009 07:40 AM

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.

Felipe Sateler 02-17-2009 10:06 AM

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Josselin Mouette 02-17-2009 10:32 AM

Python related changes for unstable/squeeze
 
Le mardi 17 fvrier 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.

Josselin Mouette 02-17-2009 11:05 AM

Python related changes for unstable/squeeze
 
Le lundi 16 fvrier 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.

Bernd Zeimetz 02-17-2009 01:03 PM

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


All times are GMT. The time now is 10:34 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.