Re: The best way to package a Python module?

[Jean-Paul Calderone]

On Mon, 16 Jun 2008 08:39:52 +1000, Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

>Jean-Paul Calderone <exarkun@divmod .comwrites:
>

>On Mon, 16 Jun 2008 01:37:47 +0900, js <ebgssth@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
>

[Ben Finney]

Re: The best way to package a Python module?

Jean-Paul Calderone <exarkun@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

[js]

Re: The best way to package a Python module?

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
<bignose+hate s-spam@benfinney. id.auwrote:

Jean-Paul Calderone <exarkun@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