Currently, calibre is a big show stopper in python 2 to 3 migration. It seems, that calibre works with Python 3 but needs thorough testing. In the calibre Python3 pull request is mentioned that arch users can decide, whether to use the Python 3 version. Maybe this would be useful for Gentoo, too. A possibility is to provide a live ebuild, where python_single_target can be switched to Python 3 to help testing it out. See also here: https://github.com/kovidgoyal/calibre/tree/py3 https://github.com/kovidgoyal/calibre/blob/master/README.python3 https://github.com/kovidgoyal/calibre/pull/870 Reproducible: Always
Norbert Preining prepared an experimental package of calibre with python 3 support for debian: https://packages.debian.org/experimental/source/calibre * the Python3 version is experimental * practically all external plugins will be broken, and you will need to remove them from ~/.config/calibre/plugins (source: https://www.preining.info/blog/2019/10/calibre-4-2-based-on-python3-in-debian-experimental/) Perhaps we can learn from it.
I created an Arch Linux AUR package that builds both python2 and python3, back in April: https://github.com/kovidgoyal/calibre/pull/870#issuecomment-486385154 The current [community] package for Arch Linux now builds both as well, and users can sync the "calibre" binary package for python2 support, or "calibre-python3" for python3 support -- they are co-installable, as well. Feel free to copy from https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/calibre P.S. Norbert Preining is incorrect that plugins need to be removed, they will simply fail to load at startup if they are incompatible, and thus not show up, or else raise error dialogs at runtime *iff* you try to use them. calibre itself won't stop working. Some plugins are ported to python3 already: https://www.mobileread.com/forums/showthread.php?t=325721
Created attachment 602202 [details] calibre beta version for python 3 support I have just made an ebuild for calibre with python 3. I took a very simple, fast and hackish aproach: Use the 4.7 ebuild and make minimal modifications to use the upstream beta release 4.99.2 and do not care about python 2 support. First I needed to update dev-python/mechanize to a newer one to make it python 3 compatible. Just copied the mechanize-0.3.6.ebuild to mechanize-0.4.5.ebuild and added python3_{5,6,7,8} to PYTHON_COMPAT. This compiled fine. Then I copied calibre-4.7.0.ebuild to calibre-4.99.2.ebuild and made a few modifications. See attached ebuild. This seems to work. I have just opened calibre and looked into a single book, so it is by no mean tested properly. Note: The upstream calibre beta requires python >= 3.7. As I am currently running the gentoo default python 3.6, in the ebuild I do patch the setup.py to only require python 3.6. This may cause trouble. Note: As many plugins have not been ported to python 3 yet, it would be better to make it possible to have both a python 2 and a python 3 version (as Eli have done for Arch). I do not have that need right now, so I took the simpler approach.
@Saxtorph as I understand I can disable line2 of src_prepare() to get python-3.7 ? I'll try now your ebuild with new upstream beta: 4.99.4
Created attachment 604198 [details, diff] calibre-4.9.1-disable_python_version_check.patch See also calibre-4.9.1-r1.ebuild and calibre-4.9.1_add_python3_support.diff
Created attachment 604200 [details] calibre-4.9.1-r1.ebuild
Created attachment 604202 [details, diff] calibre-4.9.1_add_python3_support.diff
Do not use calibre-4.9.1-disable_python_version_check.patch Just export CALIBRE_PY3_PORT to the environment... it explicitly exists to disable the version check "if you know what you're doing"...
My motivation for the patch rather than the export: If CALIBRE_PY3_PORT is exported and upstream changes their implementation of the check (or removes the check), then there are a number of possible outcomes: the ebuild might fail verbosely, or it might not fail and introduce a bug, or if the check is removed then everything continues working but the export is no longer needed (and should ideally be removed from the ebuild). If instead the patch is applied and upstream changes the check in any way, then a clear failure occurs when the patch fails to apply, and the maintainers will fix things before version bumping. As we saw with `sed -e 's/calibre.ebooks.BeautifulSoup/BeautifulSoup/'` (https://bugs.gentoo.org/705088), obsolete ebuild-level changes can stick around for a while and my hope is that the patch will be more resistant to this than the export.
I just do a git diff v${old_version} v${new_version} -- setup/ setup.py bypy/sources.json I haven't missed a dependency change or addition yet. > If CALIBRE_PY3_PORT is exported and upstream changes their implementation of the check (or removes the check), then there are a number of possible outcomes: the ebuild might fail verbosely, or it might not fail and introduce a bug, or if the check is removed then everything continues working but the export is no longer needed (and should ideally be removed from the ebuild). It is intended to be the official way to build calibre on python3, until such time as it is stabilized, which will be announced in the changelog and remove the check (so it is no longer needed). There is no reason to think the check will be modified to require a different change. > If instead the patch is applied and upstream changes the check in any way, then a clear failure occurs when the patch fails to apply, and the maintainers will fix things before version bumping. How did bug 702692 ever exist? This totally prevented compilation in the first place and should never pass any sort of test. > As we saw with `sed -e 's/calibre.ebooks.BeautifulSoup/BeautifulSoup/'` (https://bugs.gentoo.org/705088), obsolete ebuild-level changes can stick around for a while and my hope is that the patch will be more resistant to this than the export. No, you're wrong. The real problem is that your sed line broke the code which actually used BeautifulSoup in subtle ways due to the fact that it was only vendored into calibre because it was a forked version. The other real problem is that if you ran the testsuite, you would have noticed bug 705088 immediately. In fact, you'd have noticed bug 699628 and bug 697048 too. The testsuite is *designed* to find missing dependencies and suchlike, because it tries to ensure every file is importable, and runs many of the internal functions. It explicitly checks for the presence of modules which are commonly overlooked, in src/calibre/test_build.py The ebuild is still full of "sed ... || die" even though sed will only die when the input file is missing, so maybe you'd like to fix those too?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63d5384e4204ea4b9c8bc03b2e885029107ca8d9 commit 63d5384e4204ea4b9c8bc03b2e885029107ca8d9 Author: Nicholas Meyer <nickaristocrates@gmail.com> AuthorDate: 2020-01-24 18:30:27 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-25 08:47:24 +0000 app-text/calibre: 4.9.1-r1 revbump for python3 support Closes: https://github.com/gentoo/gentoo/pull/14427 Closes: https://bugs.gentoo.org/702676 Signed-off-by: Nicholas Meyer <nickaristocrates@gmail.com> Signed-off-by: Zac Medico <zmedico@gentoo.org> app-text/calibre/calibre-4.9.1-r1.ebuild | 269 +++++++++++++++++++++++++++++++ 1 file changed, 269 insertions(+)
(In reply to Eli Schwartz from comment #10) > It is intended to be the official way to build calibre on python3, until > such time as it is stabilized, which will be announced in the changelog and > remove the check (so it is no longer needed). There is no reason to think > the check will be modified to require a different change. Yeah the CALIBRE_PY3_PORT variable works for me. > The other real problem is that if you ran the testsuite, you would have > noticed bug 705088 immediately. In fact, you'd have noticed bug 699628 and > bug 697048 too. The testsuite is *designed* to find missing dependencies and > suchlike, because it tries to ensure every file is importable, and runs many > of the internal functions. It explicitly checks for the presence of modules > which are commonly overlooked, in src/calibre/test_build.py Yeah it would be nice to enable the testsuite in the ebuild. > The ebuild is still full of "sed ... || die" even though sed will only die > when the input file is missing, so maybe you'd like to fix those too? Well I'd prefer to send fixes upstream if possible.
