FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-16-2009, 06:33 PM
Matthias Klose
 
Default 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 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.

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.


Common installation location for shared code
--------------------------------------------

The source files for code (public modules) which is shared between
Python versions are currently located in different paths:

- /usr/share/pycentral/<binary package name>
- /usr/share/pysupport/<binary package name>
- /usr/share/pyshared

With this approach the Debian packaging tools (dpkg) cannot handle
file conflicts and replaces themself anymore. Errors are delayed to
the python packaging tools which either ignore these kind of errors or
have to replicate the conflicts/replaces checks.

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'.


Use of exactly one location in sys.path
---------------------------------------

Depending on the python packaging helper, public modules are available
in different locations on sys.path. Having parts of python packages
or upstream plugin systems installed into different locations may
break the python package or the plugin system. To avoid this situation
we do have the policy (section 2.1, second paragraph) that such
packages must use the same location (means: the same python packaging
helper). This part of the policy tends to be ignored.

- The import order is changed; this issue was raised earlier. See
http://lists.debian.org/debian-python/2006/01/msg00065.html
The use of relative imports (introduced in 2.5) make this more
obvious.

- Plugin systems derive the location for plugins from their
installation location. It is not an upstream bug if Debian
packages different plugins with different python packaging helpers.

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.


Avoid runtime dependencies on python packaging helpers
------------------------------------------------------

During upgrades or distribution upgrades, public python modules are
not available for use, or they may be in an inconsistent state. This
is the time between removal of old version / unpacking new version and
the postinst configuration, when the python packaging helpers are run
and the public modules made available in sys.path. There are
currently work arounds implemented to shorten the window of
unavailability:

- 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.

- Already create the symlinked files in the preinst step, because
the time between running the preinst and unpacking the new version
is much shorter.

Ideally I would like to see public python modules available after
unpack without the help of any helper application. This is possible
by creating the symlinks while creating the package and including
these in the package instead of creating these at installation time.
The only configuration needed at installation time would be
byte-compilation.

The advantage would be a more robust upgrade path.

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.

If this cannot be done for all packages, this should be done for a
subset of "core" modules and extensions.

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.


Various
-------

There are other things which may be worth a look.

- 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).

- 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.


I will start uploading python2.6 and related packages, then proceed
with python3.x in the next weeks.

Matthias


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-16-2009, 08:03 PM
Piotr Ożarowski
 
Default Python related changes for unstable/squeeze

[debian-python@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.4&2.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 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)

great idea

> - /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.

is "local/" missing in this path or do you want to simply rename site-packages
into dist-packages?

>
> 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?

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?

[1] http://groups.google.com/group/pylons-discuss/browse_thread/thread/86c713cdf9c7a54d/a53a64d8670f76ac
[2] http://workaround.org/easy-install-debian

> If needed we can provide a symlink /usr/lib/pythonX.Y/site-packages
> pointing to dist-packages.
>
>
> Common installation location for shared code
> --------------------------------------------
>
> The source files for code (public modules) which is shared between
> Python versions are currently located in different paths:
>
> - /usr/share/pycentral/<binary package name>
> - /usr/share/pysupport/<binary package name>
> - /usr/share/pyshared
>
> With this approach the Debian packaging tools (dpkg) cannot handle
> file conflicts and replaces themself anymore. Errors are delayed to
> the python packaging tools which either ignore these kind of errors or
> have to replicate the conflicts/replaces checks.
>
> 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'.

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) or I will not even try to convince Joss to fix #478178[3]
;-P

> Use of exactly one location in sys.path
> ---------------------------------------
>
> Depending on the python packaging helper, public modules are available
> in different locations on sys.path. Having parts of python packages
> or upstream plugin systems installed into different locations may
> break the python package or the plugin system. To avoid this situation
> we do have the policy (section 2.1, second paragraph) that such
> packages must use the same location (means: the same python packaging
> helper). This part of the policy tends to be ignored.
>
> - The import order is changed; this issue was raised earlier. See
> http://lists.debian.org/debian-python/2006/01/msg00065.html
> The use of relative imports (introduced in 2.5) make this more
> obvious.
>
> - Plugin systems derive the location for plugins from their
> installation location. It is not an upstream bug if Debian
> packages different plugins with different python packaging helpers.
>
> 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.

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)


> Avoid runtime dependencies on python packaging helpers
> ------------------------------------------------------
>
> During upgrades or distribution upgrades, public python modules are
> not available for use, or they may be in an inconsistent state. This
> is the time between removal of old version / unpacking new version and
> the postinst configuration, when the python packaging helpers are run
> and the public modules made available in sys.path. There are
> currently work arounds implemented to shorten the window of
> unavailability:
>
> - 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.
>
> - Already create the symlinked files in the preinst step, because
> the time between running the preinst and unpacking the new version
> is much shorter.
>
> Ideally I would like to see public python modules available after
> unpack without the help of any helper application. This is possible
> by creating the symlinks while creating the package and including
> these in the package instead of creating these at installation time.
> The only configuration needed at installation time would be
> byte-compilation.
>
> The advantage would be a more robust upgrade path.
>
> 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

>
> If this cannot be done for all packages, this should be done for a
> subset of "core" modules and extensions.
>
> 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.
>
>
> Various
> -------
>
> There are other things which may be worth a look.
>
> - 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).
>
> - 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


>
>
> I will start uploading python2.6 and related packages, then proceed
> with python3.x in the next weeks.
>
> Matthias

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 should add this to the Python policy, IMO)

--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
 
Old 02-16-2009, 08:13 PM
Josselin Mouette
 
Default 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.
 
Old 02-16-2009, 08:33 PM
Matthias Klose
 
Default 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.4&2.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 should add this to the Python policy, IMO)

"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"

Matthias


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-16-2009, 08:42 PM
Josselin Mouette
 
Default 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.
 
Old 02-16-2009, 09:02 PM
Ondrej Certik
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-16-2009, 09:15 PM
Matthias Klose
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 03:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org