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 783531 - Meson cleanups
Meson cleanups
Status: RESOLVED OBSOLETE
Product: gnome-tweak-tool
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Tweak Tool maintainer(s)
GNOME Tweak Tool maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-06-07 20:39 UTC by Patrick Griffis (tingping)
Modified: 2018-01-24 15:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build: Remove build-time checks for run-time deps (1.28 KB, patch)
2017-06-07 20:42 UTC, Patrick Griffis (tingping)
committed Details | Review
build: Remove dependency on C compiler (600 bytes, patch)
2017-06-07 20:43 UTC, Patrick Griffis (tingping)
committed Details | Review
build: Have installed scripts respect python version (2.28 KB, patch)
2017-06-07 20:43 UTC, Patrick Griffis (tingping)
needs-work Details | Review
build: Rewrite post-install script in python (2.08 KB, patch)
2017-06-07 20:43 UTC, Patrick Griffis (tingping)
committed Details | Review
Consistently use /usr/bin/env python3 shebangs (1.07 KB, patch)
2017-06-09 17:58 UTC, Patrick Griffis (tingping)
committed Details | Review

Description Patrick Griffis (tingping) 2017-06-07 20:39:48 UTC
Just various cleanups, patches to be attached...
Comment 1 Patrick Griffis (tingping) 2017-06-07 20:42:39 UTC
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.
Comment 2 Patrick Griffis (tingping) 2017-06-07 20:43:06 UTC
Created attachment 353361 [details] [review]
build: Remove dependency on C compiler

This is not used.
Comment 3 Patrick Griffis (tingping) 2017-06-07 20:43:16 UTC
Created attachment 353362 [details] [review]
build: Have installed scripts respect python version
Comment 4 Patrick Griffis (tingping) 2017-06-07 20:43:30 UTC
Created attachment 353363 [details] [review]
build: Rewrite post-install script in python

There is no reason to depend upon shell.
Comment 5 Patrick Griffis (tingping) 2017-06-07 20:44:58 UTC
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.
Comment 6 Jeremy Bicha 2017-06-07 23:12:10 UTC
Review of attachment 353360 [details] [review]:

Thanks
Comment 7 Jeremy Bicha 2017-06-07 23:13:58 UTC
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.
Comment 8 Jeremy Bicha 2017-06-07 23:14:12 UTC
Review of attachment 353361 [details] [review]:

Thanks
Comment 9 Jeremy Bicha 2017-06-07 23:16:47 UTC
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.
Comment 10 Jeremy Bicha 2017-06-07 23:18:03 UTC
Review of attachment 353363 [details] [review]:

I don't think this hurt anything to not be written in Python, but thanks anyway!
Comment 11 Jeremy Bicha 2017-06-07 23:21:38 UTC
(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!
Comment 12 Patrick Griffis (tingping) 2017-06-07 23:42:19 UTC
(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.
Comment 13 Jeremy Bicha 2017-06-08 00:34:04 UTC
(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
Comment 14 Patrick Griffis (tingping) 2017-06-08 01:15:20 UTC
(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.
Comment 15 Patrick Griffis (tingping) 2017-06-08 01:19:55 UTC
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.
Comment 16 Jeremy Bicha 2017-06-08 01:25:25 UTC
(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. :) )
Comment 17 Jeremy Bicha 2017-06-08 01:31:55 UTC
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?
Comment 18 Patrick Griffis (tingping) 2017-06-08 01:55:32 UTC
> 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.
Comment 19 Patrick Griffis (tingping) 2017-06-08 22:51:49 UTC
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
Comment 20 Jeremy Bicha 2017-06-09 01:25:37 UTC
(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
Comment 21 Patrick Griffis (tingping) 2017-06-09 04:37:14 UTC
(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?
Comment 22 Jeremy Bicha 2017-06-09 09:28:03 UTC
(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?
Comment 23 Jeremy Bicha 2017-06-09 16:44:26 UTC
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
Comment 24 Patrick Griffis (tingping) 2017-06-09 17:58:21 UTC
Created attachment 353479 [details] [review]
Consistently use /usr/bin/env python3 shebangs

This is just more flexible and supports more python installations.
Comment 25 Jeremy Bicha 2017-06-09 18:48:54 UTC
Review of attachment 353479 [details] [review]:

Thanks!
Comment 26 Patrick Griffis (tingping) 2017-06-09 20:13:11 UTC
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
Comment 27 Dominique Leuenberger 2017-06-26 15:23:08 UTC
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
Comment 28 Jeremy Bicha 2017-06-26 18:32:54 UTC
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.
Comment 29 GNOME Infrastructure Team 2018-01-24 15:23:46 UTC
-- 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.