Steve M. Robbins wrote:
> A cc is appreciated as I don't subscribe to debian-python.
>
>> On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins<steve@sumost.ca> wrote:
>> > Hi,
>> >
>> > Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
>> > python module is wrong, with reference to an oblique comment from
>> > Josselin Mouette [1].
>> >
>> > Is this true? ?What is the rationale for not versioning these shared
>> > objects?
>
> Chow Loong Jin responded noting that Python modules are loaded
> using dlopen or similar, and not by the runtime linker. He concludes
> that this implies the normal shared object versioning is not required.
>
> I don't quite follow that logic. I guess that conventionally a module
> named "fooextension.so" is loaded; i.e. without a version. However,
> one could, in principle, dlopen("fooextension.so.3") if one wanted
> multiple versions of fooextension to coexist. Is it simply the case
> that this need has not (yet?) arisen in practice?
Note that when you want to ask Python to load fooextension, you do so by
telling it "import fooextension" - the .so suffix is assumed by definition.
SONAMEs exist to allow linker to embed the version of a .so being used
at compile time into the compiled code referencing it, so the same
version can be loaded at run time.
When you are working with Python code, you don't *have* a compile time
step to mangle version information into your references to other Python
libraries. Because Python code is somewhat more loosely bound than C
code is, this isn't something that's really required. When Python
programmers do need to deal with a cataclysmic API change and both
versions must be concurrently installable, they usually deal with it by
including the major version in the module name - e.g. the "sqlite3"
python module.
> In any event, if convention dictates that modules are not versioned,
> that's fine with me. My next question is then: does it bother people
> if ITK installs versioned shared objects *in addition to* the simple
> ".so" link that is used by the python code? It does this currently,
> just because the build process treats all shared objects (modules and
> libraries) identically. Is it worth while to change this or can we
> just leave it alone?
IMO it's potentially misleading clutter, but it doesn't harm anything,
so I'd consider it something that ought to be fixed, but very much low
priority.
Max.
Attachment:
signature.asc
Description: OpenPGP digital signature