Bug 1323190 - emacs-pymacs: Provide a Python 3 subpackage
Summary: emacs-pymacs: Provide a Python 3 subpackage
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs-pymacs
Version: 25
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Sachin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PYTHON3 PY3PATCH-AVAILABLE
TreeView+ depends on / blocked
 
Reported: 2016-04-01 13:36 UTC by Tomas Orsava
Modified: 2017-04-04 09:49 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-04 09:49:02 UTC


Attachments (Terms of Use)
Provides Python3 support (5.17 KB, patch)
2016-05-28 12:26 UTC, Sachin
sacpatil: review?
Details | Diff
Provides Python3 support (5.40 KB, patch)
2016-05-30 15:35 UTC, Sachin
sacpatil: review+
Details | Diff
Provides support for Python2 as well as Python3 (5.52 KB, patch)
2016-06-09 15:42 UTC, Sachin
sacpatil: review?
Details | Diff

Description Tomas Orsava 2016-04-01 13:36:22 UTC
Upstream, this software supports Python 3. Please provide a Python 3
package for Fedora.


According to the Python packaging guidelines [0], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [1].

The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.

It's ok to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 24 as well.


If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file

Comment 1 Sachin 2016-05-28 11:01:05 UTC
I'm in the middle of porting to Python 3. But came across following issue:

https://github.com/pinard/Pymacs/issues/57

Seems that setting 
---
export LANG=en_US.UTF-8
---
in the spec file solves the issue but 'make check' fails.


When I print the value of $LANG within the spec file, it is 'C'.

Is there any way to set LANG?

Comment 2 Sachin 2016-05-28 12:26:01 UTC
Created attachment 1162593 [details]
Provides Python3 support

For review.

Comment 3 Sachin 2016-05-30 15:35:25 UTC
Created attachment 1162874 [details]
Provides Python3 support

- Added source URL as valid GitHub link to Source0
- Added License as it was missing
- Removed duplicate %install directive

Comment 4 Sachin 2016-06-09 15:42:29 UTC
Created attachment 1166355 [details]
Provides support for Python2 as well as Python3

I have tested with Emacs-24.5.1 & Emacs-pretest(25.9.94.1) for both
Python versions. It was not rigorous testing, but tried printing Python
version using Python's 'sys' module.
    
    ---
    (pymacs-exec "import sys")
    (pymacs-exec "print(sys.version)")
    ---
    
All the tests(make check) passed on both Python versions

Comment 5 Charalampos Stratakis 2016-06-10 11:05:50 UTC
So some remarks regarding the patch.

Tests are passing at the moment because they are run under Python 2. It seems upstream tests are not really compatible with Python 3. So they still should be disabled. Also at the moment the package still drags Python 2.

These lines should be removed:
BuildRequires:  python-devel # This is needed to build a python 2 package
BuildRequires:  python2-setuptools # ^
BuildRequires:  python3-docutils # python2-docutils is used to build the pdf
Requires:       python2 # This drags python 2 as runtime requirement
sed -i 's:^PYTHON =.*:PYTHON=%{__python}:g' Makefile # This makes this line to point at python 2 (we want python 3)
%{__python} setup.py install --skip-build --root %{buildroot} # this installs python 2 files, we want only python 3
%{python_sitelib}/Pymacs.py* # These are the python 2 files from the python 2 install
%{python_sitelib}/*.egg-info # ^

After these lines are removed and the tests disabled the rpm builds successfully for fedora 23, 24 and rawhide.

After these modifications doing an 'rpm -qp --requires emacs-pymacs-0.25-8.fc25.noarch.rpm" which is the resulting rpm gives us these results:

emacs(bin) >= 25.0.94
python(abi) = 3.5
python3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Which means the package depends only on python3.

Comment 6 Sachin 2016-06-10 11:23:21 UTC
cstratak,

I don't agree that the tests are passing as they are run under Python2. What is did was, I ran the build by switching to Python2 as well as Python3("alternatives --config python"). I tested the spec file on both versions independently. There is no way the Python 2 can be dragged when a package is build entirely on Python3. This is the reason I concluded that "tests passed". 

Anyways, I will again go through your suggestions and try to make it a compatible package.

Thanx for the review. 


--
Sachin

Comment 7 Charalampos Stratakis 2016-06-10 11:57:35 UTC
(In reply to Sachin from comment #6)
> cstratak,
> 
> I don't agree that the tests are passing as they are run under Python2. What
> is did was, I ran the build by switching to Python2 as well as
> Python3("alternatives --config python"). I tested the spec file on both
> versions independently. There is no way the Python 2 can be dragged when a
> package is build entirely on Python3. This is the reason I concluded that
> "tests passed". 
> 
> Anyways, I will again go through your suggestions and try to make it a
> compatible package.
> 
> Thanx for the review. 
> 
> 
> --
> Sachin

At the build log you can see 
/usr/bin/python pppp -C ppppconfig.py pymacs.el.in Pymacs.py.in tests

Last line shows that the python 2 interpreter is used to run the tests so all pass.

By incorporating my changes, at the same line you can see

/usr/bin/python3 pppp -C ppppconfig.py pymacs.el.in Pymacs.py.in tests

And the tests are failing here.

Also the package at the moment with the patch drags both dependencies and installs files for python 2 and python 3 as well. Python 3 packages shouldn't install files in python2_sitelib. The requirements of this resulting RPM are:

emacs(bin) >= 25.0.94
python(abi) = 2.7
python(abi) = 3.5
python2
python3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Comment 8 Jan Kurik 2016-07-26 05:03:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 9 Lumír Balhar 2016-08-08 07:05:01 UTC
Hello.

Do you need any help with this package? Do not hesitate to contact me.

Comment 10 Sachin 2016-08-08 07:36:18 UTC
Hi Lumir,

Can you please see the latest attachment? I have this .spec partially working. 

If I compile the package by manually changing Python version(Python 2 & 3), it works without any problem. All tests related to pymacs pass. But I build a package from Python2, the tests passes for Python2 but fails for Python3.

I can build this package skipping tests, but don't want to do that.

Let me know if you want to have a look at my latest .spec file.

Comment 11 Lumír Balhar 2016-08-09 06:59:41 UTC
Hello.

Can I reproduce your latest specfile by applying the latest attached patch to current specfile from SCM? If no, please provide your latest specfile I and will take a look.

Comment 12 Sachin 2016-08-09 10:48:03 UTC
Yes, latest attachment can be used.

Comment 13 Lumír Balhar 2016-08-11 13:59:39 UTC
To be honest I am confused about the current form of specfile. There are two options:

- Move the whole package to use only Python3
- Create two subpackages each for one Python version

But the current form looks like this options mixed together.

Which of mentioned options is preferred for this package? Is there any reason to keep Python2 support?

Just point me to right approach and I will try to help you with specfile.

Comment 14 Sachin 2016-08-12 10:09:53 UTC
Hi Lumir,

> Move the whole package to use only Python3
I m more than happy to make complete transition to Python3. I'm not sure if this is fine?

>  Create two subpackages each for one Python version

I prefer first one :)


> But the current form looks like this options mixed together.

> Which of mentioned options is preferred for this package? Is there any reason to keep Python2 support?

I see no reason to keep python2

> Just point me to right approach and I will try to help you with specfile.

You are most welcome. Thanx

Comment 15 Lumír Balhar 2016-08-17 10:43:35 UTC
Hi.

I am afraid that we shouldn't drop Python2 support. Documentation for the latest release is not available (dead links in the readme) but I found documentation for older release [0] and in the installation section is written that user can choose Python interpreter.
Another problem can appear when anybody has some scripts which depend on Pymacs and which are not Python3 compatible.

From this PoV and with new information I prefer to split this package to two subpackages - one for each Python version.

[0] http://www.red-bean.com/doc/pymacs/html/pymacs.html

What do you think about it? Do you know anybody who uses this software or is interested in Pymacs development?

Thank you for cooperation and have a nice day.

Comment 16 Sachin 2016-09-08 12:46:00 UTC
I don't know anybody using pymacs. But I can try separating package to subpackages for python version.

Comment 17 Sachin 2016-09-12 13:02:18 UTC
> From this PoV and with new information I prefer to split this package to two
> subpackages - one for each Python version.


I don't know anyone who uses this software.

Comment 18 Charalampos Stratakis 2017-04-04 09:49:02 UTC
Upstream is dead and python3 support is partial from a forked repo. As the project is not maintained upstream anymore and no live fork exists, closing this bugzilla as WONTFIX.


Note You need to log in before you can comment on or make changes to this bug.