Bug 1487848

Summary:	What is a purpose of Python 2 and 3 executables in Pelican?
Product:	[Fedora] Fedora	Reporter:	Miro Hrončok <mhroncok>
Component:	python-pelican	Assignee:	Matthias Runge <mrunge>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jamielinux, marcelo.barbosa, mcepl, mcepl, mrunge, thofmann
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-02-05 11:24:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Miro Hrončok 2017-09-02 15:03:17 UTC

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.

Comment 1 Matthias Runge 2017-09-04 06:42:50 UTC

The only difference is running on py2 or py3.

Comment 2 Miro Hrončok 2017-09-04 12:12:54 UTC

Sure. I mean, what are the consequences of running on Py2 or 3. Is it an implementation detail?

Comment 3 Matthias Runge 2017-09-04 12:33:49 UTC

Not that I'm aware of.

Comment 4 Miro Hrončok 2017-09-04 12:45:58 UTC

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?

Comment 5 Miro Hrončok 2017-09-04 12:46:25 UTC

Note that nothing in Fedora requires python-pelican or python2-pelican.

Comment 6 Matthias Runge 2017-09-04 12:55:24 UTC

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.

Comment 7 Miro Hrončok 2017-09-04 13:26:11 UTC

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.

Comment 8 Miro Hrončok 2017-12-12 15:22:16 UTC

Will send a PR that removes the Python 2 subpackage. Django 2.0 removes the Python 2 support anyway.

Comment 9 Miro Hrončok 2017-12-12 15:31:42 UTC

Please review https://src.fedoraproject.org/rpms/python-pelican/pull-request/1

Comment 10 Matthias Runge 2017-12-13 07:32:47 UTC

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.

Comment 11 Matěj Cepl 2017-12-13 15:09:10 UTC

(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.

Comment 12 Miro Hrončok 2017-12-13 20:04:08 UTC

(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.

Comment 13 Matthias Runge 2018-02-05 11:24:14 UTC

This has been solved by https://src.fedoraproject.org/rpms/python-pelican/c/a69cbc3ba2790ac93f98aa01eab1cd1aa4b4ef64?branch=master

Comment 14 Till Hofmann 2018-07-18 11:13:59 UTC

Removing python2 support broke fabric support, the deployment method recommended by upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1602431