I've just quickly scanned https://fedoramagazine.org/make-github-pages-blog-with-pelican/ and was terrified that we promote the use of Python 2 based tools. As I see it, the reason here is that pelican-quickstart command is part of the python2-pelican package. I don't know pelican much, so here comes a genuine question: **What is the difference between running pelican on Python 3 and 2? Are distinguished commands (with -2 and -3) suffixes necessary?** If they are necessary, please provide explanation and preferably put it as a comment in spec. If they are not necessary, let's get rid of the Python 2 executable. As I see it, the content for Pelican is reStructuredText, Markdown, or AsciiDoc, combined with Jinja templates. That is Python version agnostic. Users can probably write their own plugins in either Python 2 or Python 3, but do we need to support that in the package? Thanks for clarification.
The only difference is running on py2 or py3.
Sure. I mean, what are the consequences of running on Py2 or 3. Is it an implementation detail?
Not that I'm aware of.
I see two options in here: 1) remove executables from python2-, only keep them in python3- (and get rid of -3, -3.6, etc.), but keep the python2 package with the module. This will probably break upgrade path, as the executable will be gone for the users who upgraded (as it happened with tox) 2) get rid of the python2- package altogether. obsolete it form python3-. This will make the upgrade path clean. Thoughts?
Note that nothing in Fedora requires python-pelican or python2-pelican.
The py2 version does not use any suffix. https://src.fedoraproject.org/rpms/python-pelican/blob/master/f/python-pelican.spec#_169 If Python3 becomes the default, we could drop the python2 package and obsolete it.
Py 3 is the default. From the guidelines: https://fedoraproject.org/wiki/Packaging:Python#Executables_in_.2Fusr.2Fbin > If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only the Python 3 version of the executable should be packaged.
Will send a PR that removes the Python 2 subpackage. Django 2.0 removes the Python 2 support anyway.
Please review https://src.fedoraproject.org/rpms/python-pelican/pull-request/1
Thank you! The dependency to Django is somewhat artificial. pelican uses a fraction of django, which was forked and minimally patched (feedparser). The patch was not accepted upstream though.
(In reply to Miro Hrončok from comment #8) > Will send a PR that removes the Python 2 subpackage. Django 2.0 removes the > Python 2 support anyway. Wouldn't it make sense to even remove python- prefix? Pelican is an application, not a library, so it shouldn't matter to anybody what language it is written in.
(In reply to Matěj Cepl from comment #11) > Wouldn't it make sense to even remove python- prefix? Pelican is an > application, not a library, so it shouldn't matter to anybody what language > it is written in. That's why I put: Provides: %{pypi_name} == %{version}-%{release} I didn't want to rename the package, as I think this should be enough.
This has been solved by https://src.fedoraproject.org/rpms/python-pelican/c/a69cbc3ba2790ac93f98aa01eab1cd1aa4b4ef64?branch=master
Removing python2 support broke fabric support, the deployment method recommended by upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1602431