GNOME Bugzilla – Bug 763263
jedi_plugin.py hardcodes gir path as /usr/share/gir-1.0
Last modified: 2016-04-26 07:00:07 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.
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.
I think this makes sense to fix for 3.20.
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.
Is there a way to do this without using a subprocess?
(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?
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).
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.
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.
(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.
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.
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