Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gobject introspection file also bumps version string under major.minor versioning scheme #175

Open
hosiet opened this issue May 11, 2020 · 4 comments

Comments

@hosiet
Copy link

hosiet commented May 11, 2020

This is a follow-up for #174 .

Actually libmypaint is also providing optional gobject introspection support. The problem is that using gobject introspection would require explicitly specifying the version. For example on my system:

Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> gi.require_version('MyPaint', '1.5')
>>> gi.require_version('MyPaint', '1.6')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 132, in require_version
    raise ValueError('Namespace %s not available for version %s' %
ValueError: Namespace MyPaint not available for version 1.6
% dpkg -L gir1.2-mypaint-1.5
/usr/lib/x86_64-linux-gnu/girepository-1.0/MyPaint-1.5.typelib
[...]

However this version string still follows the major.minor scheme, showing similar issues like what we discussed in #174 . This iscaused by

--nsversion="$(LIBMYPAINT_API_PLATFORM_VERSION)" \
and

libmypaint/configure.ac

Lines 42 to 43 in 2d1c974

m4_define([libmypaint_api_platform_version],
[libmypaint_api_major.libmypaint_api_minor])
.

I'm not suggesting to fix it soon with a 1.6.2 release or so since few other projects are using this gir binding and that I'm not familiar with gobject introspection conventions either. Maybe we need more investigation about how other libraries are handling it.

@jplloyd
Copy link
Member

jplloyd commented May 11, 2020

Yes, to my knowledge no project has ever used those bindings, and the new functions from 1.5 and onwards are mostly not exposed via the bindings (deliberately).

I will look into how this should be handled some time later this week.

Does creating an appropriately named symlink to the existing .typelib fix the import?

@jplloyd
Copy link
Member

jplloyd commented May 12, 2020

Ok, so based on looking at: https://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=gir1.2- the gir files/package should have been suffixed with -1.0 from the start, and not updated for any other release with the same major version. There are some exceptions in that list, but only a few.

The require_version function seems to be made for distinguishing between bindings for different major versions (i.e. different packages, in practice), rather than for requiring a particular version of bindings (no ability to specify minimum/maximum versions).

Does creating an appropriately named symlink to the existing .typelib fix the import?

Answer to that question is "no". A symlink fools the require_version call, but the real version is checked during import, so it will fail anyway (if require_version has been called for the link name version, that is).

I think the thing to do here is to follow the convention of having not-so-meaningful minor versions in the gir names, i.e locking the naming to MyPaint-1.6 for any future releases in the 1.x branch, and using MyPaint-2.0 (unchanging) for the next major version (if GObject introspection support is retained, this is still undecided).

I think this is mostly academical though. Are there actually any reverse dependencies for any of the gir1.2-mypaint-xyz packages?

@hosiet
Copy link
Author

hosiet commented May 15, 2020

Yeah it's really some academical issues. I don't think any external project is using the connect introspection binding at this moment. That's also the reason I suggested that it might not be of high importance. However if such project is to exist in the future, maintaining a stable interface would be important then.

@rulyone
Copy link

rulyone commented Apr 20, 2023

I'm trying to use the libmypaint library in a python application but I'm having issues creating the bindings. Were you able to do it @hosiet ? @jplloyd any hint/help would be greatly appreciated.

So far I have tried creating a .gir file using the command g-ir-scanner /usr/local/Cellar/libmypaint/1.6.1_1/include/libmypaint --library=mypaint --namespace=Libmypaint --nsversion=1.6 --output=libmypaint-1.6.gir

The content of the file generated is:

<?xml version="1.0"?>
<!-- This file was automatically generated from C sources - DO NOT EDIT!
To affect the contents of this file, edit the original C definitions,
and/or use gtk-doc annotations.  -->
<repository version="1.2"
            xmlns="http://www.gtk.org/introspection/core/1.0"
            xmlns:c="http://www.gtk.org/introspection/c/1.0"
            xmlns:glib="http://www.gtk.org/introspection/glib/1.0">
  <namespace name="Libmypaint"
             version="1.6"
             shared-library="/usr/local/opt/libmypaint/lib/libmypaint.0.dylib"
             c:identifier-prefixes="Libmypaint"
             c:symbol-prefixes="libmypaint">
  </namespace>
</repository>

But then I'm stuck trying to use it in a python/pyside application.

For reference, I'm looking at this port to Qt https://github.com/ethiccinema/qtmypaint , so this should be possible in theory with python bindings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants