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

Manylinux2010 #5410

Merged
merged 6 commits into from
Nov 22, 2018
Merged

Manylinux2010 #5410

merged 6 commits into from
Nov 22, 2018

Conversation

wtolson
Copy link
Contributor

@wtolson wtolson commented May 15, 2018

This is an update of @markrwilliams merge request #5008. Updates the tag from manylinux2 to manylinux2010 to reflect the changes in PEP 571. Also addresses @dstufft's suggestion to not use startswith to detect the arch. Thanks to @ncoghlan for the help!

Copy link
Member

@ncoghlan ncoghlan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, just one technical suggestion to reduce risk, and a request to make one comment a bit more detailed

@@ -263,7 +280,8 @@ def get_supported(versions=None, noarch=False, platform=None,

if not noarch:
arch = platform or get_platform()
if arch.startswith('macosx'):
arch_prefix, arch_sep, arch_suffix = arch.partition('_')
if arch_prefix == 'macosx':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how the macosx platform tags are actually structured, so it would be safer to keep the startswith for this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I've reverted this line to use startswith.

elif platform is None and is_manylinux1_compatible():
arches = [arch.replace('linux', 'manylinux1'), arch]
elif arch_prefix == 'manylinux2010':
# manylinux1 wheels run on manylinux2010 systems.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the discussion on the previous PR, we should add a link to the relevant PEP section in this comment, and qualify it as "Most" wheels being compatible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the comment here. Anything else you'd like to see added? Do you have a preferred method for including log urls?

@pradyunsg pradyunsg added the S: needs triage Issues/PRs that need to be triaged label May 16, 2018
@pradyunsg pradyunsg added PEP implementation Involves some PEP and removed S: needs triage Issues/PRs that need to be triaged labels Aug 14, 2018
@pradyunsg
Copy link
Member

This LGTM. @dstufft Could you take a look?

@ofek
Copy link
Contributor

ofek commented Aug 27, 2018

Can this be merged?

@safijari
Copy link

This looks like it's ready to be merged. Is there something more that needs to be done?

@ncoghlan
Copy link
Member

@pradyunsg @dstufft @pfmoore

@ehashman recently merged the change to let auditwheel produce manylinux2010 wheels, so this is the main missing piece for general support for the new tag.

@pfmoore pfmoore merged commit 087d825 into pypa:master Nov 22, 2018
@ncoghlan
Copy link
Member

Thanks @pfmoore!

@pfmoore
Copy link
Member

pfmoore commented Nov 22, 2018

Hmm, looks like this broke the build :-(

See https://travis-ci.org/pypa/pip/builds/458357307 - can someone please submit a fix for this? It looks like a trivial lint failure - how come the CI didn't pick this up on the PR? (Sorry, I can't do it right now)

@ncoghlan
Copy link
Member

@pfmoore It could be a new check was added since the PR was last updated - if I'd thought about it, I would have suggested closing and reopening to force a fresh CI run first.

@pradyunsg pradyunsg added this to the 19.0 milestone Jan 3, 2019
@lock
Copy link

lock bot commented May 31, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 31, 2019
@lock lock bot locked as resolved and limited conversation to collaborators May 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation PEP implementation Involves some PEP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants