Re: How best to handle tools which support multiple Python runtimes
Avram Lubkin wrote: > The > second option would work as long as you don't have python3-sphinx > installed during the package build. That should be fine in a mock > build, but if someone wanted to do a rebuild on their regular system > and had python3-sphinx installed, they'd have to set the sphinx > version with the alternatives command. That's true. Well, I think we can live with that for a while and solve it by porting sphinxcontrib-adadomain. Björn Persson pgpwH5jFWSrqs.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How best to handle tools which support multiple Python runtimes
On Sun, Jul 17, 2016 at 6:09 AM, Björn Persson wrote: > It sounds like I should start trying to get sphinxcontrib-adadomain > ported to Python 3. > Definitely! > I have two possible fixes: > > > > The first would be to decouple the commands from the libraries. Since > > the package name sphinx is already taken by the search engine, > > something like python-sphinx-bin may be appropriate. Once separated, > > the command would default to python3 since the packaging guidelines > > say it Python 3 versions should be preferred when equivalent. > > If this approach is chosen, will the commands still invoke the Python 2 > version if only that one is installed? > No, the command would require the python3 version, the second option would allow the python commands to be the default if it's the only one installed. > > > The second option would be to retain the multiple versions, but to > > manage the links with alternatives so the unversioned commands will > > default to whatever version is installed and again, Python 3 would be > > preferred if both were installed. > > This approach seems like it would work for my use case. > > Ahven uses Sphinx to generate its documentation, using Sphinx's > generated makefile that invokes sphinx-build. I have ahven.spec > regenerate the documentation, but the makefile is generated upstream. > Until the Ada domain gets ported, the Ahven build will have to use the > Python 2 Sphinx, but I'd rather not encode that in ahven.spec. I want > to keep that dependency contained in python-sphinxcontrib-adadomain. > Ahven shouldn't need to even know that Sphinx is written in Python. > > If I can have python-sphinxcontrib-adadomain depend on the Python 2 > Sphinx specifically, and then have the ahven package require > python-sphinxcontrib-adadomain, plus python-sphinx or python-sphinx-bin > or whatever but not python2-sphinx, and invoke sphinx-build and know > that it will run on Python 2, then I'm satisfied. > It sounds like the first option wouldn't work for your use case, since you have a hard Python 2 dependency until sphinxcontrib-adadomain gets a Python 3 package. The only way it could work would be to modify the make file during the build. The second option would work as long as you don't have python3-sphinx installed during the package build. That should be fine in a mock build, but if someone wanted to do a rebuild on their regular system and had python3-sphinx installed, they'd have to set the sphinx version with the alternatives command. It seems like the second option, using alternatives, would be the preferred method so as to not break things. My current thinking is to implement this in the next package update, but to keep Python 2 as the default (if both are installed) for Fedora 24, then make Python 3 the default in Rawhide and Fedora 25. Avram -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How best to handle tools which support multiple Python runtimes
Avram Lubkin wrote: > Potentially there are some Sphinx > extensions that are Python version dependent, but I am not aware of > any. It sounds like I should start trying to get sphinxcontrib-adadomain ported to Python 3. > It was suggested the makefile should be changed so the Python version > that was used for sphinx-quickstart should be used for sphinx-build. > Unfortunately, that would make the file less portable. Yeah, that's not a particularly good idea. I suppose it would work for those who generate the makefile and use it themselves on the same workstation. For makefiles that are included in source tarballs it would only make the problem worse. > I have two possible fixes: > > The first would be to decouple the commands from the libraries. Since > the package name sphinx is already taken by the search engine, > something like python-sphinx-bin may be appropriate. Once separated, > the command would default to python3 since the packaging guidelines > say it Python 3 versions should be preferred when equivalent. If this approach is chosen, will the commands still invoke the Python 2 version if only that one is installed? > The second option would be to retain the multiple versions, but to > manage the links with alternatives so the unversioned commands will > default to whatever version is installed and again, Python 3 would be > preferred if both were installed. This approach seems like it would work for my use case. Ahven uses Sphinx to generate its documentation, using Sphinx's generated makefile that invokes sphinx-build. I have ahven.spec regenerate the documentation, but the makefile is generated upstream. Until the Ada domain gets ported, the Ahven build will have to use the Python 2 Sphinx, but I'd rather not encode that in ahven.spec. I want to keep that dependency contained in python-sphinxcontrib-adadomain. Ahven shouldn't need to even know that Sphinx is written in Python. If I can have python-sphinxcontrib-adadomain depend on the Python 2 Sphinx specifically, and then have the ahven package require python-sphinxcontrib-adadomain, plus python-sphinx or python-sphinx-bin or whatever but not python2-sphinx, and invoke sphinx-build and know that it will run on Python 2, then I'm satisfied. Björn Persson pgpcFIxbiCScN.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How best to handle tools which support multiple Python runtimes
As someone pointed out somewhere on IRC - we should try to invent "alternatives" to python packages like it was done in java packages in Fedora. On Thu, Jul 14, 2016 at 3:13 PM, Miroslav Suchý wrote: > Dne 13.7.2016 v 21:15 Avram Lubkin napsal(a): >> Does anyone have any preferences, thoughts or alternative approaches? > > I do not have the solution. But I want to point out similar case, which I > recently reported against pyp2rpm: > https://github.com/fedora-python/pyp2rpm/issues/63 > > -- > Miroslav Suchy, RHCA > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How best to handle tools which support multiple Python runtimes
Dne 13.7.2016 v 21:15 Avram Lubkin napsal(a): > Does anyone have any preferences, thoughts or alternative approaches? I do not have the solution. But I want to point out similar case, which I recently reported against pyp2rpm: https://github.com/fedora-python/pyp2rpm/issues/63 -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
How best to handle tools which support multiple Python runtimes
I'm a co-maintainer for the python-sphinx package. There's a bug [1] I'd like to address, but I'd like some input on what I was thinking. There was some discussion about this on FPC ticket [2], but nothing workable really came out of that. I also attempted to get input [3] from the Sphinx community, but didn't receive a response. For background, python-sphinx is available for both Python2 and Python3. It is primarily a library, but provides four commands for convenience: sphinx-build, sphinx-quickstart, sphinx-apidoc, sphinx-autogen. Here's an example of how these commands are currently made available to the user: /usr/bin/sphinx-build -> sphinx-build-2 /usr/bin/sphinx-build-2 -> sphinx-build-2.7 /usr/bin/sphinx-build-2.7 (#!/usr/bin/python2) /usr/bin/sphinx-build-3 -> sphinx-build-3.4 /usr/bin/sphinx-build-3.4 (#!/usr/bin/python3) It should be noted, all of these commands are just used to call entry points and don't have any of their own logic. Here are their equivalents: sphinx-buildpython -m sphinx sphinx-quickstartpython -m sphinx.quickstart sphinx-apidoc python -m sphinx.apidoc sphinx-autogen python -m sphinx.ext.autosummary.generate Sphinx itself isn't Python version specific and maintains compatibility regardless of what Python version you are using or if you switch back and forth. Potentially there are some Sphinx extensions that are Python version dependent, but I am not aware of any. Use cases for Sphinx are all over the place. For example, I rarely use the commands and call sphinx through setuptools 99% of the time. Other people use the commands exclusively, and still others use the makefile created by sphinx-quickstart as their primary way to call it. It's this last one is where we are seeing the biggest problem and is described in the bug. Essentially, sphinx-quickstart-3 is used to create a makefile which lists sphinx-build as the build command. But sphinx-build is currently linked to the python2 version, which may not be expected, and won't necessarily be installed. It was suggested the makefile should be changed so the Python version that was used for sphinx-quickstart should be used for sphinx-build. Unfortunately, that would make the file less portable. I have two possible fixes: The first would be to decouple the commands from the libraries. Since the package name sphinx is already taken by the search engine, something like python-sphinx-bin may be appropriate. Once separated, the command would default to python3 since the packaging guidelines say it Python 3 versions should be preferred when equivalent. The second option would be to retain the multiple versions, but to manage the links with alternatives so the unversioned commands will default to whatever version is installed and again, Python 3 would be preferred if both were installed. Does anyone have any preferences, thoughts or alternative approaches? Avram [1] https://bugzilla.redhat.com/show_bug.cgi?id=1321413 [2] https://fedorahosted.org/fpc/ticket/612 [3] https://groups.google.com/forum/#!topic/sphinx-dev/vdFeOEj4EKg -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org