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 <file>..." 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.
“pygobject” is not a python dependency and can therefore not be used as install
requirement for setup.py. To avoid an error message and let the application
start fine, this needs to be removed from setup.py.
