dev-python/nautilus-python: Version bump

[MeisterP]

add python3 support

Bug: https://bugs.gentoo.org/665764
Package-Manager: Portage-2.3.40, Repoman-2.3.9

[MeisterP]

build.log

[gentoo-bot]

Pull Request assignment

Areas affected: ebuilds
Packages affected: dev-python/nautilus-python

dev-python/nautilus-python: tetromino

At least one of the listed packages is maintained entirely by non-GitHub developers!

Bugs linked: 665764

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2018-09-12 11:37 UTC
Newest commit scanned: cb2dccc
Status: ✅ good

No issues found

[okias]

Hello @MeisterP could you also incorporate my patch for introspection flag drop for later versions?

https://bugs.gentoo.org/show_bug.cgi?id=665354

Thanks
David

[leio]

This breaks concurrently installed nautilus extensions written in python only compatible with python3 and extensions only compatible with python2 due to python-single-r1 and probably the nature of it.
With this PR, there are no safeguards in place, and some existing packages would break if this is merged as-is.

[okias]

@leio what you propose? migrate to different eclass?

[leio]

I don't see anything else possible than making all nautilus-python consumers (packages that ship a nautilus extension written in python and thus depending [or failing to depend] on nautilus-python for it to work) compatible with both python2 and python3 and then switch nautilus-python over to python3 then.
Some packages are currently even depending on nautilus-python[${PYTHON_USEDEP}] now, which is wrong and they shouldn't, as nautilus-python is python-single-r1 and that dep is meaningless - it just happens to work fine now because there's only 2_7, thus effectively no-op. But it does tell me that some packages are most definitely not ready for a nautilus-python that supports only python3.

To support both, we would probably have to provide two different nautilus extensions, that are side by side and look for extensions in different directories. BUT if nautilus extensions are loaded into the same process space as nautilus, then both of these nautilus extensions (that provide support for extensions written in python) would end up loaded in the same process space together, and thing will horribly break due to the different python.so's providing the same symbols (and that DOES break things badly, I've felt it elsewhere before I fixed things up).

As that's a lot more work, I will for now bump nautilus-python in main tree for us without supporting python3 (the bump alone has fixes and sanity for python2 too), and someone would hopefully help with mapping the python3 compat situation of nautilus-python consumers, etc, and we go from there. This is low priority for me personally, because well, it's more important to have gnome 3.30 :)

[leio]

I'm closing this PR, as I'm merging my own version bump.
But to still review it, in the interest of teaching, here are some notes on what I did different:

• Kept PYTHON_COMPAT on only 2_7 due to reasons discussed above and on bugzilla (other packages would break)
• Updated to EAPI-6; in practice that just meant removing GCONF_DEBUG setting, unless I missed something else
• No losing of arch keywords. A bump should only downgrade existing keywords to their ~arch counterparts (typically by running ekeyword ~all <ebuild file> on it), not lose those you can't test on. That is, unless it misses some new dependent keywords, so it wouldn't be repoman clean (but in that case a PR should make note of it and ensure a re-keywording request doesn't get forgotten, etc).
• nautilus dep to >=3.0, not >=3.20. I didn't find any version checks as advertised in NEWS file anywhere, but as that suggests nautilus-3 at least, and we don't have older (or older then 3.20 for that fact), still raised the dep to at least 3.0 (configure check is still 2.32).
• gtk-doc in autotools disted tarballs is generally already pregenerated (and they fixed that in these newer versions). So there is no need for a USE=doc, but rather an always required gtk-doc-am build dependency (the package is tiny), which will update all the docs (via gtkdoc-rebase tool) to offline viewing as much as possible at the time thanks to standard gtk-doc.make rules for autotools builds. So removed the hacks as well, but also the IUSE=doc stuff fully and added gtk-doc-am dep.
• No unnecessary python_setup calls added. python-single-r1 already exports a pkg_setup, and that will be used, it calls python_setup, and as it is done in pkg_setup, it is sufficient. gnome.eclass doesn't have a pkg_setup, thus no override issues.
• Removed unused deprecated eutils inherit

[MeisterP]

@leio Thanks for taking the time to review. Much appreciated.

I don't get why depending on nautilus-python[${PYTHON_USEDEP}] is wrong though. My understanding was that with python-single-r1, just one on of the implementations in PYTHON_COMPAT is supported. But this doesn't make depending on a particular implementation wrong...

https://wiki.gentoo.org/wiki/Project:Python/python-single-r1#PYTHON_USEDEP