Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setup.py environment markers not supported on EPEL7 #38

Open
mmathesius opened this issue Jun 5, 2018 · 8 comments
Open

setup.py environment markers not supported on EPEL7 #38

mmathesius opened this issue Jun 5, 2018 · 8 comments

Comments

@mmathesius
Copy link
Contributor

When attempting to build the python-aexpect package for EPEL7, the build fails with the following error:

+ /usr/bin/python2 setup.py build '--executable=/usr/bin/python2 -s'
error in aexpect setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers

It appears the older version of python-setuptools available for EPEL7 (package python-setuptools-0.9.8-7.el7) does not support environment markers--which were introduced into setup.py by a recent update.

It should also be noted that the offending line of setup.py is specifying a requirement for python-subprocess32 which is not currently available for EPEL7, but should be made available soon by https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-947a26a22d

@mmathesius
Copy link
Contributor Author

Also possibly related: is the python-subprocess32 package really a build time requirement as indicated by the BuildRequires: python-subprocess32 line in the current python-aexpect.spec? Of only a runtime requirement as indicated in setup.py?

@mmathesius
Copy link
Contributor Author

FYI, I have worked around this build issue in the Fedora/EPEL package by adding the following to the %prep section of the spec file to strip any environment markers:

%if 0%{?rhel} && 0%{?rhel} <= 7
# old setuptools does not support environment markers
sed -i "/install_requires=/,/]/s/;[^']*//g" setup.py
%endif

Feel free to review https://src.fedoraproject.org/rpms/python-aexpect/pull-request/2

@ldoktor
Copy link
Contributor

ldoktor commented Jun 6, 2018

@mmathesius it'd be probably better to wait for 1.5.1, which should have this addressed... 1.5.0 is considered broken.

@mmathesius
Copy link
Contributor Author

@ldoktor Thanks for the warning! I'll hold off merging https://src.fedoraproject.org/rpms/python-aexpect/pull-request/2 and releasing a new Fedora package until 1.5.1 is available.

@mmathesius
Copy link
Contributor Author

@ldoktor PR #39 fixes this issue.

Will a 1.5.1 release be forthcoming? Or shall I package 1.5.0 including PR #39 as a patch? Or is 1.5.0 considered broken in other ways? Thanks!

@ldoktor
Copy link
Contributor

ldoktor commented Jun 13, 2018

Current master is fixed and works well, I'm waiting on @lmr to release the new version. Alternatively @clebergnu might take care of that when the time allows it (hopefully soon)

@clebergnu
Copy link
Contributor

@ldoktor 1.5.1 is already tagged. Pushing to PyPI now.

@mmathesius
Copy link
Contributor Author

Thanks for the fix and new tag!

I have updated the downstream Fedora package pull request to use 1.5.1 and skip the hacky patch listed above. Feedback is welcomed on https://src.fedoraproject.org/rpms/python-aexpect/pull-request/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants