{"action":"created","issue":{"url":"https://api.github.com/repos/pypa/pip/issues/3844","repository_url":"https://api.github.com/repos/pypa/pip","labels_url":"https://api.github.com/repos/pypa/pip/issues/3844/labels{/name}","comments_url":"https://api.github.com/repos/pypa/pip/issues/3844/comments","events_url":"https://api.github.com/repos/pypa/pip/issues/3844/events","html_url":"https://github.com/pypa/pip/issues/3844","id":165465800,"number":3844,"title":"manylinux1 comes first?","user":{"login":"dholth","id":208018,"avatar_url":"https://avatars.githubusercontent.com/u/208018?v=3","gravatar_id":"","url":"https://api.github.com/users/dholth","html_url":"https://github.com/dholth","followers_url":"https://api.github.com/users/dholth/followers","following_url":"https://api.github.com/users/dholth/following{/other_user}","gists_url":"https://api.github.com/users/dholth/gists{/gist_id}","starred_url":"https://api.github.com/users/dholth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dholth/subscriptions","organizations_url":"https://api.github.com/users/dholth/orgs","repos_url":"https://api.github.com/users/dholth/repos","events_url":"https://api.github.com/users/dholth/events{/privacy}","received_events_url":"https://api.github.com/users/dholth/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-07-14T03:00:15Z","updated_at":"2016-12-16T19:10:08Z","closed_at":null,"body":"I was surprised to see 'manylinux1' come first in pip.pep425tags.get_supported(). Would this cause pip to prefer a pypi-hosted manylinux1 wheel over a locally built linux_x86_64 wheel? I would expect the \n'linux_x86_64' wheel to count as \"more specific to the current system\" and needing to come first.\n\nPropose switching the order of each pair of elements in this list from pip.pep425tags.get_supported():\n\n```\n[('cp35', 'cp35m', 'manylinux1_x86_64'),\n ('cp35', 'cp35m', 'linux_x86_64'),\n ('cp35', 'abi3', 'manylinux1_x86_64'),\n ('cp35', 'abi3', 'linux_x86_64'),\n ('cp35', 'none', 'manylinux1_x86_64'),\n ('cp35', 'none', 'linux_x86_64'),\n ('py3', 'none', 'manylinux1_x86_64'),\n ('py3', 'none', 'linux_x86_64'),\n```\n"},"comment":{"url":"https://api.github.com/repos/pypa/pip/issues/comments/267671982","html_url":"https://github.com/pypa/pip/issues/3844#issuecomment-267671982","issue_url":"https://api.github.com/repos/pypa/pip/issues/3844","id":267671982,"user":{"login":"dstufft","id":145979,"avatar_url":"https://avatars.githubusercontent.com/u/145979?v=3","gravatar_id":"","url":"https://api.github.com/users/dstufft","html_url":"https://github.com/dstufft","followers_url":"https://api.github.com/users/dstufft/followers","following_url":"https://api.github.com/users/dstufft/following{/other_user}","gists_url":"https://api.github.com/users/dstufft/gists{/gist_id}","starred_url":"https://api.github.com/users/dstufft/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dstufft/subscriptions","organizations_url":"https://api.github.com/users/dstufft/orgs","repos_url":"https://api.github.com/users/dstufft/repos","events_url":"https://api.github.com/users/dstufft/events{/privacy}","received_events_url":"https://api.github.com/users/dstufft/received_events","type":"User","site_admin":false},"created_at":"2016-12-16T19:10:08Z","updated_at":"2016-12-16T19:10:08Z","body":"> I'm describing a practical problem and I had not seen the recent PR resolution. ... A random machine id tag would be a different way to solve the same problem of selectively overriding broken pypi wheels, with its own workarounds for sharing wheels between similar machines.\r\n\r\nI agree this is a problem, and had offered two solutions in #3921 that would, in my opinion, solve it better, one that is automatic and allows a \"zero configuration\" approach and one which is opt-in and allows a \"shared amongst many machines\" approach. I believe these options are better because they don't involve making something that is *logically* less specific be considered more specific (and ontop of that, they remove the requirement to manage compatibility externally to pip).\r\n\r\nI believe that the only reason it's defensible at all to swap the order of these two things, is because *generally* people will put ``manylinux1`` wheels on PyPI and *generally* they will not put the ``linux_*`` wheels on PyPI, but wheel will generate them by default. However there is nothing stopping them from publishing a ``linux_*`` wheel to PyPI today (and in fact, it could be super useful in non C library cases, like if you want to ship man pages to Linux but not to Windows for instance).\r\n\r\n> It's discouraging to argue with you, and I usually step away from attempts to contribute to Python packaging for a while after doing so, so you won't have to worry about me for a while.\r\n\r\nI was going to just ignore this, but I don't think that's a very good thing to do. First off, I do not want *anyone* to feel discouraged to contributing to Python packaging. If you can point out what it is that I do (either here or privately is fine) that you find discouraging I can try to work on it. I suspect that it largely has to do with my own personal frustration over my perception that your solutions to problems and feature ideas tend to focus on expediency and what you think would be cool, rather than long term maintainability and an overall consistency of the related concepts. I don't know if that's how you *actually* think/view it or not, but that is how it comes across to me, and that frustrates me and I suspect that frustration might come out."}}
{"actor":{"display_login":"dstufft"}}