[Python-Dev] versioned .so files for Python 3.2

[Barry Warsaw]

On Jun 26, 2010, at 06:50 PM, Scott Dial wrote:

>On 6/26/2010 4:06 PM, Matthias Klose wrote:
>> On 25.06.2010 22:12, James Y Knight wrote:
>>> On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
>>>> Placing .so files together does not simplify that install process in any
>>>> way. You will still have to handle such packages in a special way.
>>>
>>> This is a good point, but I think still falls short of a solution. For a
>>> package like lxml, indeed you are correct. Since debian needs to build
>>> it once per version, it could just put the entire package (.py files and
>>> .so files) into a different per-python-version directory.
>> 
>> This is what is currently done.  This will increase the size of packages
>> by duplicating the .py files, or you have to install the .py in a common
>> location (irrelevant to sys.path), and provide (sym)links to the
>> expected location.
>
>"This is what is currently done"  and "provide (sym)links to the
>expected location" are conflicting statements.

I think Matthias was referring to "what is currently done" to your statement
"debian needs to build it once per version".  Providing symlinks is how we are
able to make it appear that there are version-specific py files without
actually doing so.

>If you are symlinking .py files from a shared location, then that is not the
>same as "just install the package into a version-specific location". What
>motivation is there for preferring symlinks?

This reduces .py file duplications in distro packages.

>Who cares if a ditro package install yields duplicate .py files? Nor am
>I motivated by having to carry duplicate .py files in a distribution
>package (I imagine the compression of duplicate .py files is amazing).

It might be amazing, but it's still a significant overhead.  As I've
described, multiply that by all the py files in all the distro packages
containing Python source code, and then still try to fit it on a CDROM.

>What happens to the distro packaging if a python package splits the
>codebase between 2.x and 3.x (meaning they have distinct .py files)?

The Debian/Ubuntu approach to Python 2/3 support is to provide them in
separate distro packages.  E.g. for Python package foo, you would have Debuntu
package python-foo (for the Python 2.x version) and python3-foo.  We do not
share source between Python 2 and 3 versions, at least not yet <wink>.  This
doesn't hurt us much because the number of Python packages that are source
compatible between the two is pretty low (Benjamin's 'six' package might
change that :), and not much depends on Python 3 yet.

>As someone else mentioned, how is virtualenv going to interact with packages
>that install like this?

This is a good question, but I *think* it won't affect it much at all.  To
test for sure I'd either need a Python 3 compatible virtualenv or backport my
patch to Python 2.6 and 2.7.  But still, I'm not sure it would matter since
the same shared library import suffix is used in either case.  I actually
think version-specific search paths would have a greater impact on
virtualenv.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100630/c3175d50/attachment.pgp>