New Python policy

I have updated the Python policy document based on the
discussions on
the list. An updated DebianDoc (and HTML and text files) can
be found at
http:
//people.debian.org/~piman/python-policy/.

It:
 0) Removes a lot of cruft/debate from the document itself
 1) Explains X*-Python-Version
 2) Explains that we don't want tight dependencies
 3) Deprecates /usr/lib/site-python
 4) Outlines using python-support/central with debhelper
 5) Tries to cover more on private modules

It does not:
 1) Cover CDBS, since I don't know how to use it properly
 2) Give examples for Python packages without using
debhelper;
    I suspect those are now almost impossible to make
sanely.

Probably:
 1) The "Upgrade Procedure" section needs work
(from RMs)
 2) I have some details wrong
 3) My explanations could be clearer (but I feel it's an
    improvement over the old structure)
-- 
Joe Wreschnig <pimansacredchao.net>

Joe Wreschnig (pimansacredchao.net):
> I have updated the Python policy document based on the
discussions on
> the list. An updated DebianDoc (and HTML and text
files) can be found at
> http:
//people.debian.org/~piman/python-policy/.

great work!

[...]
> It does not:
>  1) Cover CDBS, since I don't know how to use it
properly
>  2) Give examples for Python packages without using
debhelper;
>     I suspect those are now almost impossible to make
sanely.

What about an Egg support? I think it's worth mentioning in
policy

I'm talking about:
* --single-version-externally-managed parameter passed to
  `setup.py install` or DEB_PYTHON_INSTALL_ARGS_ALL (CDBS)
* Egg's dirname's issue (python's/module's version in
dirname)

-- 
-=[     Piotr Ozarowski     ]=-
-=[ http://www.ozarowski.pl
]=-

Piotr Ozarowski writes:
> What about an Egg support? I think it's worth
mentioning in policy
> 
> I'm talking about:
> * --single-version-externally-managed parameter passed
to
>   `setup.py install` or DEB_PYTHON_INSTALL_ARGS_ALL
(CDBS)
> * Egg's dirname's issue (python's/module's version
in dirname)

the python version information should be dropped, the
module's version
can be dropped. Checked with Phil Eby.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble?
Contact listmasterlists.debian.org

Hi

On Mon, 12 Jun 2006 02:29:51 -0500
Joe Wreschnig <pimansacredchao.net> wrote:

> I have updated the Python policy document based on the
discussions on
> the list. An updated DebianDoc (and HTML and text
files) can be found at
> http:
//people.debian.org/~piman/python-policy/.

How about adding example for building compiled extensions?
Otherwise
there will be used many ways to produce binaries for all
supported
python versions.

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

> How about adding example for building compiled
extensions? Otherwise
> there will be used many ways to produce binaries for
all supported
> python versions.

 - Packaging examples
   - CDBS (not yet available)
   - python-central (http://python-modules.alioth.debian.org/python-c
entral_howto.txt)
   - python-support (http://wiki.de
bian.org/DebianPythonFAQ)

If a package has just extensions, then you don't need
python-support
or python-central at all.  Just put all extensions for each
supported
python version into the same python-foo package.  We do not
explicitely disallow having copies of the same .py files in
/usr/lib/pythonX.Y, so that can be done as well (example is
python-newt which comes with one extension and one module).

Extensions and modules in packages (the python sense, a
directory with
an __init__.py) must end up in the same directory.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble?
Contact listmasterlists.debian.org

Hi,

On Mon, 12 Jun 2006, Michal Čihař wrote:
> On Mon, 12 Jun 2006 02:29:51 -0500
> Joe Wreschnig <pimansacredchao.net> wrote:
> 
> > I have updated the Python policy document based on
the discussions on
> > the list. An updated DebianDoc (and HTML and text
files) can be found at
> > http:
//people.debian.org/~piman/python-policy/.
> 
> How about adding example for building compiled
extensions? Otherwise
> there will be used many ways to produce binaries for
all supported
> python versions.

There will be example packages soon we hope.

In the mean time, I can tell you that you will have to
Build-Depends on
"python (>= 2.3.5-6), python-all-dev" and
that you should use `pyversions
-r debian/control` to find out the list of python versions
that you must
use to build the package with, then your job in the rules
file is to do
something like that:

for python in $(PYVERS); do \
    $$python setup.py ...; \
done

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.o
uaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble?
Contact listmasterlists.debian.org

Hi

no need to CC me...

On Mon, 12 Jun 2006 12:34:18 +0200
Matthias Klose <dokocs.tu-berlin.de> wrote:

>  - Packaging examples
>    - CDBS (not yet available)
>    - python-central (http://python-modules.alioth.debian.org/python-c
entral_howto.txt)
>    - python-support (http://wiki.de
bian.org/DebianPythonFAQ)
> 
> If a package has just extensions, then you don't need
python-support
> or python-central at all.  Just put all extensions for
each supported
> python version into the same python-foo package.  We do
not
> explicitely disallow having copies of the same .py
files in
> /usr/lib/pythonX.Y, so that can be done as well
(example is
> python-newt which comes with one extension and one
module).

I understand this, I just want that policy mentions what is
suggested
way to get all supported python versions (and thus what
pythonX.Y to
call setup.py with).

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

Hi

On Mon, 12 Jun 2006 13:18:53 +0200
Raphael Hertzog <hertzogdebian.org> wrote:

> In the mean time, I can tell you that you will have to
Build-Depends on
> "python (>= 2.3.5-6), python-all-dev"
and that you should use `pyversions
> -r debian/control` to find out the list of python
versions that you must
> use to build the package with,
[...]

This is exactly information I miss there right now.

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

Coin,

Matthias Klose <dokocs.tu-berlin.de> writes:

>> How about adding example for building compiled
extensions? Otherwise
>> there will be used many ways to produce binaries
for all supported
>> python versions.
>
>  - Packaging examples
>    - CDBS (not yet available)

A packaging example can be found here :
  http:
//perso.duckcorp.org/duck/soya-new-policy/

What needs to be done:
  - use the splited dh_* script intead of the former
dh_python updated
    script (will be done today)
  - use the script in python-dev for build version
calculation instead
    of the internal code (when a test package is available)
  - move the class into cdbs itself (i plan to contact Peter
today)
  - test it widely

This class is aware of builddeps generation, so you can use
the feature
manually to avoid missing stuff. dh_* would handle
tool-specific
dependencies.

The CDBS documentation would be done soon (in the original
documentation not in the package, for those aware of the
fork issue).


Btw, unfortunately apt is absolutely unable to handle
versioned
dependencies when those have switched from real dependencies
to
provides, then you may have to fix packages depending on
your libraries.
In my cdbs packaging example i will have to fix balazar (but
not slune).

-- 
Marc Dequènes (Duck)