GNOME Bugzilla – Bug 783531
Meson cleanups
Last modified: 2018-01-24 15:23:46 UTC
Just various cleanups, patches to be attached...
Created attachment 353360 [details] [review] build: Remove build-time checks for run-time deps These are honestly so ancient I don't think we should even care. I doubt any developer tests this against Gtk 3.10.
Created attachment 353361 [details] [review] build: Remove dependency on C compiler This is not used.
Created attachment 353362 [details] [review] build: Have installed scripts respect python version
Created attachment 353363 [details] [review] build: Rewrite post-install script in python There is no reason to depend upon shell.
I haven't done it yet, but `defs.py.in` should be moved to `gnome-tweak-tool.in`, it makes no sense to have the config that points to where a module is be within the module not the script in bin.
Review of attachment 353360 [details] [review]: Thanks
Review of attachment 353360 [details] [review]: I think we should add these to README or something so that distros can set the binary runtime dependencies easily and correctly. Otherwise, it is common in GNOME for stuff to have build dependencies that aren't strictly required for building as a workaround for that problem.
Review of attachment 353361 [details] [review]: Thanks
Review of attachment 353362 [details] [review]: Can you explain why you think this is helpful? By the way, I corrected the inhibitor's shebang to python3 at the same time you were pushing the patches here.
Review of attachment 353363 [details] [review]: I don't think this hurt anything to not be written in Python, but thanks anyway!
(In reply to Patrick Griffis (tingping) from comment #5) > I haven't done it yet, but `defs.py.in` should be moved to > `gnome-tweak-tool.in`, it makes no sense to have the config that points to > where a module is be within the module not the script in bin. Yes, defs.py causes some problems for people trying to run gnome-tweak-tool from git so I'd really appreciate that!
(In reply to Jeremy Bicha from comment #9) > Review of attachment 353362 [details] [review] [review]: > > Can you explain why you think this is helpful? > > By the way, I corrected the inhibitor's shebang to python3 at the same time > you were pushing the patches here. It is plausible for a distro to have multiple python versions so hard coding `python3` might be less than ideal. Various distribution linting tools also warn about shebangs not explicitly matching a version.
(In reply to Patrick Griffis (tingping) from comment #12) > It is plausible for a distro to have multiple python versions so hard coding > `python3` might be less than ideal. Various distribution linting tools also > warn about shebangs not explicitly matching a version. Why is it less than ideal? gnome-tweak-tool should work with any python3 (at least 3.2; I haven't tested on anything lower than 3.5). Therefore, according to Debian Python packaging policy #!/usr/bin/python3 is appropriate. https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter
(In reply to Jeremy Bicha from comment #13) > (In reply to Patrick Griffis (tingping) from comment #12) > > It is plausible for a distro to have multiple python versions so hard coding > > `python3` might be less than ideal. Various distribution linting tools also > > warn about shebangs not explicitly matching a version. > > Why is it less than ideal? gnome-tweak-tool should work with any python3 (at > least 3.2; I haven't tested on anything lower than 3.5). > > Therefore, according to Debian Python packaging policy #!/usr/bin/python3 is > appropriate. > > https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s- > interpreter Ok some examples: User installs with python 3.4, python3 points to 3.5, installation is broken because it can't find the module. User is on rolling distribution (with weak dependencies, grr Arch) installs with 3.6, 3.7 comes out, installation is broken because it can't find the module. If we version the shebang situation one is fixed and situation two has a more clear error.
There is a valid alternative of not installing the module into the python path and installing into an unversioned private dir `share/gtweak` or whatever. If you prefer that approach.
(In reply to Patrick Griffis (tingping) from comment #14) > User installs with python 3.4, python3 points to 3.5, installation is broken > because it can't find the module. > > User is on rolling distribution (with weak dependencies, grr Arch) installs > with 3.6, 3.7 comes out, installation is broken because it can't find the > module. On Debian, this package's modules are installed to /usr/lib/python3/dist-packages/gtweak/ Can't other sane distros just override pythondir to get the same effect? Can you point me to some documentation to prove your point? (I showed you mine first. :) )
I think you're arguing something different anyway. There's nothing in the inhibitor script that cares about what version of python3 is being used. And on my Ubuntu system, I changed the shebang to /usr/bin/python3.5 and it still worked. Maybe you're thinking about whatever defs.py replacement you have planned. But maybe that could be smart enough to try multiple directories if that's a problem?
> Can't other sane distros just override pythondir to get the same effect? To my knowledge not a single other distro does this and changing default behavior is usually frowned upon so its always going to be in `/usr/lib/python3.x/site-packages/gtweak` a versioned directory. > But maybe that could be smart enough to try multiple directories if that's a problem? Well as mentioned we can just not install into python directories and that largely satisfies my complaint.
Attachment 353360 [details] pushed as 1b7567c - build: Remove build-time checks for run-time deps Attachment 353361 [details] pushed as f7ab942 - build: Remove dependency on C compiler Attachment 353363 [details] pushed as 83ae105 - build: Rewrite post-install script in python
(In reply to Patrick Griffis (tingping) from comment #19) > Attachment 353363 [details] pushed as 83ae105 - build: Rewrite post-install > script in python We used /usr/bin/env before this commit. I would prefer we use the same shebang everywhere. https://git.gnome.org/browse/gnome-tweak-tool/commit/?id=7a0d4223
(In reply to Jeremy Bicha from comment #20) > We used /usr/bin/env before this commit. I would prefer we use the same > shebang everywhere. > https://git.gnome.org/browse/gnome-tweak-tool/commit/?id=7a0d4223 Why would you want to hardcode a path that is less portable?
(In reply to Patrick Griffis (tingping) from comment #21) > Why would you want to hardcode a path that is less portable? Portable to where and why?
Review of attachment 353362 [details] [review]: As I said in comment #17, I don't think this particular change is useful. Feel free to change all the shebangs to either include /usr/bin/env or exclude it. I like the idea of moving Tweak Tool's files to pkgdatadir
Created attachment 353479 [details] [review] Consistently use /usr/bin/env python3 shebangs This is just more flexible and supports more python installations.
Review of attachment 353479 [details] [review]: Thanks!
Comment on attachment 353479 [details] [review] Consistently use /usr/bin/env python3 shebangs Attachment 353479 [details] pushed as 969c0c8 - Consistently use /usr/bin/env python3 shebangs
imho, /usr/bin/env FOO is the right thing for 'non-distro provided installs' - non-integrated, non-tested, non-working :) - as soon as a distro ships, they should be able to have /usr/bin/python3 (or python3.5 or whatever they do) why is '/usr/bin/env FOO' 'bad' (my opinion) it even picks up a binary/script called 'FOO' from the users ~/bin/ (if in $PATH) - definitively not what any sane distro would want to send to their users (arguably, no distro does a good job in patching that nonsense away though) So any user 'playing' with python3 because he wants to start testing stuff might get a no-longer working distro package
Debian (and derivatives like Ubuntu) automatically overrides the shebang to /usr/bin/python3 for gnome-tweak-tool 3.25.3. I don't see any good reason for Tweak Tool to be used with any other python than the system installed python. It's not like Tweak Tool is using bleeding-edge Python code.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-tweaks/issues/96.