After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763263 - jedi_plugin.py hardcodes gir path as /usr/share/gir-1.0
jedi_plugin.py hardcodes gir path as /usr/share/gir-1.0
Status: RESOLVED FIXED
Product: gnome-builder
Classification: Other
Component: plugins
3.19.x
Other FreeBSD
: Normal normal
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-07 19:39 UTC by Ting-Wei Lan
Modified: 2016-04-26 07:00 UTC
See Also:
GNOME target: ---
GNOME version: 3.19/3.20


Attachments
jedi: don't hardcode the path of gir files (8.77 KB, patch)
2016-04-22 20:08 UTC, Ting-Wei Lan
none Details | Review
jedi: don't hardcode the path of gir files (8.66 KB, patch)
2016-04-23 10:35 UTC, Ting-Wei Lan
committed Details | Review

Description Ting-Wei Lan 2016-03-07 19:39:50 UTC
On FreeBSD and OpenBSD, /usr prefix is reserved for the operating system itself and should not be modified by packages. Software installed from repositories usually uses /usr/local prefix, so the path of gir is usually /usr/local/share/gir-1.0. (I say 'usually' here because it is possible to build and install packages in prefix other than /usr/local with the ports system, but it is likely to be broken because few people use non-default prefixes.)

If we don't want to have another hardcoded path in jedi_plugin.py, I think it may be possible to figure out directories containing gir files from XDG_DATA_DIRS and GI_TYPELIB_PATH environment variables, or use the default when they are unset.
Comment 1 Christian Hergert 2016-03-07 21:41:45 UTC
This sounds reasonable to me.

The way to get the directories with pkg-config is:

 pkg-config --variable=typelibdir gobject-introspection-1.0
 pkg-config --variable=girdir gobject-introspection-1.0

I think any environment variables we extract should probably be additive to that list.
Comment 2 Christian Hergert 2016-03-07 21:47:24 UTC
I think this makes sense to fix for 3.20.
Comment 3 Ting-Wei Lan 2016-04-22 20:08:24 UTC
Created attachment 326571 [details] [review]
jedi: don't hardcode the path of gir files

FreeBSD and OpenBSD don't install GNOME and most other software
packages with /usr prefix. The installation prefix can be changed by
users, but it must not be /usr to avoid breaking the system. It is
usually better to rely on environment variables and pkg-config to
provide the path.

This change also allows reading gir files from multiple prefixes,
enabling the use of gir files installed in a JHBuild prefix.

Unfortuneately, I didn't have much time making a patch after reporting
this bug, so it couldn't get fixed before 3.20 was released.
Comment 4 Elad Alfassa 2016-04-22 20:17:00 UTC
Is there a way to do this without using a subprocess?
Comment 5 Ting-Wei Lan 2016-04-22 20:27:10 UTC
(In reply to Elad Alfassa from comment #4)
> Is there a way to do this without using a subprocess?

Do you mean we should read the .pc file in the python script itself (which can be complex), or we can avoid using pkg-config?
Comment 6 Elad Alfassa 2016-04-22 20:36:51 UTC
Maybe you could use something like https://pypi.python.org/pypi/pykg-config/ or another library instead of forking a subprocess to parse the pkgconfig files...

I didn't read your code thoroughly, but I can see you support multiple paths for GIR files... won't this cause a problem if you have different minor versions of the same library installed in different paths? The INSERT statement probably won't fail because we don't have any indexes set (even though we probably should), but you'd be keeping the same data twice (which is inefficient) and there's no way to guarantee the latest version is the one that will be displayed to the user (minor versions might not change the API, but they can still update the documentation text).
Comment 7 Elad Alfassa 2016-04-22 20:44:24 UTC
Another idea: since Builder's build scripts probably know (or have the option to know) where the preferred GIR path is, wouldn't it be better if the GIR path in the plugin would be a placeholder, and the Makefile would fill it in according to Builder's build configuration? This would probably require less code change and less operations done during runtime.
Comment 8 Christian Hergert 2016-04-22 21:15:56 UTC
It's probably time we move jedi_plugin.py to jedi_plugin/__init__.py. Then we could add a jed_plugin/config.py.in which gets the @@GIR_DIR@@ filled in at compile time.
Comment 9 Ting-Wei Lan 2016-04-23 10:30:44 UTC
(In reply to Elad Alfassa from comment #4)
> Is there a way to do this without using a subprocess?

I will use GIRepository.Repository.get_default().get_search_path() to replace the pkg-config subprocess.

(In reply to Elad Alfassa from comment #6)
> I didn't read your code thoroughly, but I can see you support multiple paths
> for GIR files... won't this cause a problem if you have different minor
> versions of the same library installed in different paths? The INSERT
> statement probably won't fail because we don't have any indexes set (even
> though we probably should), but you'd be keeping the same data twice (which
> is inefficient) and there's no way to guarantee the latest version is the
> one that will be displayed to the user (minor versions might not change the
> API, but they can still update the documentation text).

Yes, I already see there are two rows storing documentation for the same symbol in my girdoc.db. GIR_PATH_LIST is ordered, and I can add a check to make sure that each filename can only be processed once. However, if users use gnome-builder in both system environment and jhbuild environment, duplicate items can still be inserted.

(In reply to Elad Alfassa from comment #7)
> Another idea: since Builder's build scripts probably know (or have the
> option to know) where the preferred GIR path is, wouldn't it be better if
> the GIR path in the plugin would be a placeholder, and the Makefile would
> fill it in according to Builder's build configuration? This would probably
> require less code change and less operations done during runtime.
(In reply to Christian Hergert from comment #8)
> It's probably time we move jedi_plugin.py to jedi_plugin/__init__.py. Then
> we could add a jed_plugin/config.py.in which gets the @@GIR_DIR@@ filled in
> at compile time.

I think gnome-builder is not able to know the path at the build time because users may install gnome-builder in a prefix not shared with other packages.
Comment 10 Ting-Wei Lan 2016-04-23 10:35:24 UTC
Created attachment 326591 [details] [review]
jedi: don't hardcode the path of gir files

FreeBSD and OpenBSD don't install GNOME and most other software
packages with /usr prefix. The installation prefix can be changed by
users, but it must not be /usr to avoid breaking the system. It is
usually better to rely on environment variables and gobject-introspection
itself to provide the path.

This change also allows reading gir files from multiple prefixes,
enabling the use of gir files installed in a JHBuild prefix. gir files
located in different directories but with the same name are not processed
twice to avoid inserting duplicate items into the database.
Comment 11 Christian Hergert 2016-04-26 07:00:04 UTC
Seems fine to me, we can iterate if necessary to fixup anything that breaks.
My simple test worked fine though.

Attachment 326591 [details] pushed as 8485b33 - jedi: don't hardcode the path of gir files