By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,206 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,206 IT Pros & Developers. It's quick & easy.

Re: The best way to package a Python module?

P: n/a
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
Share this Question
Share on Google+
2 Replies


P: n/a
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

P: n/a
js
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

This discussion thread is closed

Replies have been disabled for this discussion.