Re: The best way to package a Python module?

On Mon, 16 Jun 2008 08:39:52 +1000, Ben Finney <bi************ ****@benfinney. id.auwrote:

>Jean-Paul Calderone <ex*****@divmod .comwrites:

>On Mon, 16 Jun 2008 01:37:47 +0900, js <eb*****@gmail. comwrote:
>By "package", I meant APT, Ports for BSD, MacPorts, etc.

I don't know about ports or macport, but Debian has recently
switched to a different policy for python packages which does not
involve as many Python version specific copies of things. You might
want to look at "python-central" and stdeb.

The version-specific copies are still there in the latest Debian
practices. That's a necessary artefact of the per-version
site-packages of Python.

What has changed is that the tools in common use for Debian packaging
of Python libraries have taken on the role of generating those
per-version copies at install time.

This means that, for pure-Python libraries, the source package need
only contain a version-independent source and a declaration of which
Python versions it should be installed for. The installation tool will
take care of making the per-version copies in various places.

Maybe. I'm no expert on Debian packaging. However,

exarkun@boson:~ $ ls -l /usr/lib/python2.{4,5}/site-packages/sqlite/main.py
lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.4/site-packages/sqlite/main.py -/usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.5/site-packages/sqlite/main.py -/usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
exarkun@boson:~ $

That doesn't seem to agree with your statement. Am I missing something?

Jean-Paul

>
--
\ "Nothing so needs reforming as other people's habits." -- Mark |
`\ Twain, _Pudd'n'head Wilson_ |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Jun 27 '08 #1

Subscribe Reply

2028

Ben Finney

Jean-Paul Calderone <ex*****@divmod .comwrites:

What has changed is that the tools in common use for Debian
packaging of Python libraries have taken on the role of generating
those per-version copies at install time.

exarkun@boson:~ $ ls -l /usr/lib/python2.{4,5}/site-packages/sqlite/main.py
lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.4/site-packages/sqlite/main.py -/usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.5/site-packages/sqlite/main.py -/usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
exarkun@boson:~ $

That doesn't seem to agree with your statement. Am I missing something?

You are missing an inspection of the contents of the actual package
file. The package file itself contains only a single copy of the
Python module (at /usr/share/pycentral/site-packages/sqlite/main.py).

What you see there on your filesystem was created at install time; the
installation tool figures out, at install time, which Python versions
need to be supported on this particular system, and creates those
symlinks.

Thus, the change that's occurred is that the user doesn't need to
choose between "Python SQLite library for Python 2.4" and "Python
SQLite library for Python 2.5".

There is no longer a separation at the package level by Python
version, so the user merely needs to choose (given your example) the
single "Python SQLite library", and the install process takes care of
setting it up for all supported versions of Python on the system.

--
\ â€œ[Freedom of speech] isn't something somebody else gives you. |
`\ That's something you give to yourself.â€ â€”_Hocus Pocus_, |
_o__) Kurt Vonnegut |
Ben Finney

Jun 27 '08 #2

Thanks everyone for details.
I'll try stealing some of the good bits of python-central of debian
for my purpose.

On Mon, Jun 16, 2008 at 10:43 AM, Ben Finney
<bi************ ****@benfinney. id.auwrote:

Jean-Paul Calderone <ex*****@divmod .comwrites:

>What has changed is that the tools in common use for Debian
packaging of Python libraries have taken on the role of generating
those per-version copies at install time.

exarkun@boson: ~$ ls -l /usr/lib/python2.{4,5}/site-packages/sqlite/main.py
lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.4/site-packages/sqlite/main.py -/usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.5/site-packages/sqlite/main.py -/usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
exarkun@boson: ~$

That doesn't seem to agree with your statement. Am I missing something?

You are missing an inspection of the contents of the actual package
file. The package file itself contains only a single copy of the
Python module (at /usr/share/pycentral/site-packages/sqlite/main.py).

What you see there on your filesystem was created at install time; the
installation tool figures out, at install time, which Python versions
need to be supported on this particular system, and creates those
symlinks.

Thus, the change that's occurred is that the user doesn't need to
choose between "Python SQLite library for Python 2.4" and "Python
SQLite library for Python 2.5".

There is no longer a separation at the package level by Python
version, so the user merely needs to choose (given your example) the
single "Python SQLite library", and the install process takes care of
setting it up for all supported versions of Python on the system.

--
\ "[Freedom of speech] isn't something somebody else gives you. |
`\ That's something you give to yourself." —_Hocus Pocus_, |
_o__) Kurt Vonnegut |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Jun 27 '08 #3

Similar topics

3809

package module import name clash with global package

by: George P | last post by:

I've run into a strange package related namespace problem. Follow these steps (on UNIX system) to illustrate: ------------------------- mkdir /tmp/mypkg cd /tmp/mypkg touch __init__.py echo 'import os\ndef test():\n print os.getcwd()' > os.py cd /tmp

Python

1366

Importing package modules from C-extension

by: Mark English | last post by:

Basic problem: If there is a C-extension module in a package and it tries to import another python module in the same package without using the fully qualified path, the import fails. Config: Python 2.4 on Windows 2000 For example: mypackage contains:

Python

3848

Package organization: where to put 'common' modules?

by: fortepianissimo | last post by:

Say I have the following package organization in a system I'm developing: A |----B |----C |----D I have a module, say 'foo', that both package D and B require. What is the best practice in terms of creating a 'common' package that hosts

Python

1465

package search

by: boris | last post by:

I have two directories, lib1 and lib2, that both contain the package foo, one with the submodule mod1 and the other with the submodule mod2: $ ls lib*/foo/ lib1/foo/: __init__.py __init__.pyc mod1.py mod1.pyc lib2/foo/: __init__.py __init__.pyc mod2.py mod2.pyc

Python

1983

guidance needed: best practice for script packaging

by: Alan Isaac | last post by:

This is a simple question about actual practice. I just want to know how you (yes you) are approaching this problem. The problem: What is the recommended packaging of demo scripts or test scripts for a package to be distributed to others to "play with". (I.e., without "installing".)

Python

824

The best way to package a Python module?

by: js | last post by:

Hi list, I'm trying to build a package for python modules. When I just wanted to have a package for Python2.5, this is an easy task, but in most cases, it's not enough. Sometimes I need python2.4, 2.5, 2.6 or 3.0 etc. The problem is coming from the fact that python installs its modules into version-independent place as follow.