Re: Fwd: SONAME for python modules is bad?
On Sat Jul 25 06:27, Matthias Klose wrote: > Wrong. It's already done, including a version in the file name and having > a symlink to an unversioned jar. It should be possible to do something > similiar with jni bindings. That's not a complete solution. 1. it's not reflected in package names, 2. the unversioned symlink is included in the jar, so they are non coinstallable, 3. the versions are specified as package versions, not incompatible upgrade bumps, which means you transition on every new upstream release, 4. there's no automatic resolution of these versions for classpaths or dependencies, which makes all the transitions either very painful, or everyone ignores the versions and therefore you don't get any benefit from it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Fwd: SONAME for python modules is bad?
On 25.07.2009 05:47, Matthew Johnson wrote: On Sat Jul 25 11:28, Mathieu Malaterre wrote: On Fri, Jul 24, 2009 at 7:45 PM, Max Bowsher wrote: ... It would be extremely nice too if all wrap language would adopt the same convention. So that toolkit such as VTK/ITK/GDCM wrapping their interface into multiple languages (namely: Tcl, Python, Java, C#) could simply decide: (1) Allow SONAME (2) Use a directory convention libfoo-$SOVERSION/$NAME.so for packaging mutiple modules. It is unclear to me what you are trying to standardize. How does one install multiple version of the same python/java/cli module ? (speaking for Java) At the moment, you don't. Wrong. It's already done, including a version in the file name and having a symlink to an unversioned jar. It should be possible to do something similiar with jni bindings. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fwd: SONAME for python modules is bad?
On Sat Jul 25 11:28, Mathieu Malaterre wrote: > On Fri, Jul 24, 2009 at 7:45 PM, Max Bowsher wrote: > ... > >> It would be extremely nice too if all wrap language would adopt the > >> same convention. So that toolkit such as VTK/ITK/GDCM wrapping their > >> interface into multiple languages (namely: Tcl, Python, Java, C#) > >> could simply decide: > >> (1) Allow SONAME > >> (2) Use a directory convention libfoo-$SOVERSION/$NAME.so > >> > >> for packaging mutiple modules. > > > > It is unclear to me what you are trying to standardize. > > How does one install multiple version of the same python/java/cli module ? (speaking for Java) At the moment, you don't. However, it's on the agenda for our BoF later this week at debconf. I'd like to see a coherent plan for transitions (wrt modules in Java). When it comes to glue; generally it's assumed that the same source package will be building both the java side of the glue and the C side, so there's no need to SONAME it for that. However, if we want parallel installable versions of the java library, that naming needs to extend to all of files shipped in the library. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: SONAME for python modules is bad?
On Fri, Jul 24, 2009 at 07:13:19PM +0100, Max Bowsher wrote: > 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. Agreed. Thanks, -Steve signature.asc Description: Digital signature
Re: SONAME for python modules is bad?
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 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.
signature.asc
Description: OpenPGP digital signature
Re: SONAME for python modules is bad?
Hi,
A cc is appreciated as I don't subscribe to debian-python.
On Fri, Jul 24, 2009 at 03:49:16PM +0200, Mathieu Malaterre wrote:
> On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins 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?
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?
> > Is there any "more official" document that mandates this? ?For
> > example, the python policy?
>
> This issue was raised by Denis Barbier. [...]
> It would be extremely nice too if all wrap language would adopt the
> same convention.
That would be nice.
Personally, I'd settle for each language having a clear policy written
down (in a location that I can easily find) so that I don't have to
guess. ;-)
Regards,
-Steve
signature.asc
Description: Digital signature
Re: SONAME for python modules is bad?
On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins 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?
>
> Is there any "more official" document that mandates this? For
> example, the python policy?
This issue was raised by Denis Barbier. This makes particular sense
for the C#/Java target language since one setup a proper
LD_LIBRARY_PATH and then an internal mechanism load the internal glue
lib. The version of the glue lib is not very important in this case
and furhtermore cannot even be expressed AFAIK. For instance, in Java:
static {
try {
System.loadLibrary("gdcmjni");
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load. \n" + e);
System.exit(1);
}
}
In C#:
[DllImport("gdcmsharpglue", EntryPoint="CSharp_ImageWriterUpcast")]
It would be extremely nice too if all wrap language would adopt the
same convention. So that toolkit such as VTK/ITK/GDCM wrapping their
interface into multiple languages (namely: Tcl, Python, Java, C#)
could simply decide:
(1) Allow SONAME
(2) Use a directory convention libfoo-$SOVERSION/$NAME.so
for packaging mutiple modules.
I know that Python had some other convention such as preprending
underscore, but I have never seen any need for SONAME on modules.
2cts,
--
Mathieu
http://mathieumalaterre.com
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: SONAME for python modules is bad?
On Wednesday 22,July,2009 02:47 PM, Steve M. Robbins 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? > > Is there any "more official" document that mandates this? For > example, the python policy? I think it's more of something like the libtool versioning scheme is used only for libraries that are linked in using by the dynamic linker during runtime, i.e. stuff in the LD_LIBRARY_PATH, or the usual lib directories: /usr/lib, /usr/local/lib, etc. Python modules are loaded using dlopen or some similar mechanism if I'm not mistaken, and hence should not be versioned using the libtool versioning scheme. They're much like plugins for certain applications, e.g. /usr/lib/geany/*.so for Geany, and /usr/lib/nautilus/extensions-*/*.so for Nautilus, except that in this case, it's for Python. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
SONAME for python modules is bad?
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? Is there any "more official" document that mandates this? For example, the python policy? Thanks, -Steve [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378049#25 signature.asc Description: Digital signature
