From 54717a3491c82efee6faf6abee69a09e6a09de84 Mon Sep 17 00:00:00 2001 From: Jeremy Fleischman Date: Thu, 25 Aug 2022 09:15:30 -0700 Subject: [PATCH] Fix build When doing a `python setup.py build` on my machine, I found that `build/lib` would not end up with a compiled gresource file until the second invocation of `python setup.py build`. Before: $ python setup.py build running build running build_py creating build creating build/lib creating build/lib/mcg copying mcg/connectionpanel.py -> build/lib/mcg copying mcg/shortcutsdialog.py -> build/lib/mcg copying mcg/serverpanel.py -> build/lib/mcg copying mcg/application.py -> build/lib/mcg copying mcg/window.py -> build/lib/mcg copying mcg/playlistpanel.py -> build/lib/mcg copying mcg/utils.py -> build/lib/mcg copying mcg/coverpanel.py -> build/lib/mcg copying mcg/infodialog.py -> build/lib/mcg copying mcg/librarypanel.py -> build/lib/mcg copying mcg/client.py -> build/lib/mcg copying mcg/zeroconf.py -> build/lib/mcg copying mcg/mcg.py -> build/lib/mcg copying mcg/__init__.py -> build/lib/mcg copying mcg/albumheaderbar.py -> build/lib/mcg package init file 'data/__init__.py' not found (or not a regular file) compiling gresources compiling gschemas $ ls build/lib/mcg/data/ ls: cannot access 'build/lib/mcg/data/': No such file or directory Note how there is no data directory at all. Now check out what happens on the second build: $ git status On branch main Your branch is up to date with 'origin/main'. Untracked files: (use "git add ..." to include in what will be committed) data/gschemas.compiled data/xyz.suruatoel.mcg.gresource nothing added to commit but untracked files present (use "git add" to track) $ python setup.py build running build running build_py package init file 'data/__init__.py' not found (or not a regular file) creating build/lib/mcg/data copying data/xyz.suruatoel.mcg.gresource -> build/lib/mcg/data compiling gresources compiling gschemas $ ls build/lib/mcg/data/ xyz.suruatoel.mcg.gresource That's because the first build generated the compiled schemas and resources (you can see evidence of that in `git status`), and then the second build was able to copy the gresource file over according to the `package_data` rules. The fix I've introduced here is to just do the compilations *before* we call `super(...).run(...)`. There might be better ways of doing this, I'm not very familiar with packaging gtk python applications. Things were even worse for the gschemas.compiled file: in addition to the ordering issue it's not even mentioned in `data_files`, so even if it does exist, it doesn't have a chance to get copied over when installed. So I've added it to the `data_files` section. I don't know if that'll play nicely or not with the existing `--no-compile-schemas` flag. --- setup.py | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/setup.py b/setup.py index 6237487..9d400af 100644 --- a/setup.py +++ b/setup.py @@ -29,11 +29,14 @@ class build_mcg(build_py): def run(self, *args, **kwargs): - super(self.__class__, self).run(*args, **kwargs) self._build_gresources() if not self.distribution.no_compile_schemas: self._build_gschemas() + # This will copy the package_data and data_files, so we need to do this + # *after* we've compiled resources and schemas. + super(self.__class__, self).run(*args, **kwargs) + def _build_gresources(self): print("compiling gresources") @@ -92,7 +95,8 @@ setup( "data/icons/mcg.svg" ]), (os.path.join('share', 'glib-2.0', 'schemas'), [ - "data/xyz.suruatoel.mcg.gschema.xml" + "data/xyz.suruatoel.mcg.gschema.xml", + "data/gschemas.compiled", ]), (os.path.join('share', 'locale', 'en', 'LC_MESSAGES'), [ 'locale/en/LC_MESSAGES/mcg.mo'