Hello all: I have been attempting to resolve the horrible easy_install behavior where compiled wheels published on pypi are not used to fulfill setup requirements. To address this issue, I have submitted pull requests to both setuptools and pip that would allow a proprietary communication method that can later be easily adjusted to be fully PEP 517 compliant, saving work while resolving a specific issue. However, everyone appears to be ignoring these pull requests, in my estimation, because PEP 517 is not fully completed. That’s fine, but partial PEP 517 compliance in one area is better than nothing at all, which is currently the default scenario. Regards, xoviat
On 6 August 2017 at 00:18, 12345 67890 <xoviat@gmail.com> wrote:
I have been attempting to resolve the horrible easy_install behavior where compiled wheels published on pypi are not used to fulfill setup requirements. To address this issue, I have submitted pull requests to both setuptools and pip that would allow a proprietary communication method that can later be easily adjusted to be fully PEP 517 compliant, saving work while resolving a specific issue.
However, everyone appears to be ignoring these pull requests, in my estimation, because PEP 517 is not fully completed. That’s fine, but partial PEP 517 compliance in one area is better than nothing at all, which is currently the default scenario.
That's not correct (at least in my case). I'm "ignoring", as you put it, your PR, because I work on pip in my spare time, and I have extremely limited time to spend on pip, and I'd rather invest my time in other areas. That's my choice, and you complaining about my priorities won't affect it. *All* of the pip developers have very limited time, and complaining that you are being ignored is frankly not the best way of getting attention. To be explicit, I'm currently spending my time on: 1. Mailing list discussions (because I can work on these when not at a PC with a development setup). 2. Triage of issues (explaining misunderstandings, redirecting issues that are actually for other projects, confirming issues are real and requesting PRs, etc) 3. Reviews of PRs where other core pip maintainers or key developers need them. That pretty much uses up all of the time I have available for pip at the moment. I'd also note that I've never myself encountered the "horrible easy_install behavior" you mention, and your description doesn't remind me of any specific issues that have been raised. That's not to say that it's not a significant issue - maybe it is - but if you want to persuade me that it's urgent enough to merit me spending time on it, I'd appreciate links to your PR, and to one or more issues reported against pip explaining how the problem is affecting users. Also, it's important to remember that *no* change will improve things for users until it's in a released version of pip. The next planned version is pip 10, and I for one hope that PEP 517 will be in that version - so why rush in a fix that will only need modifying once PEP 517 is implemented? Even if your proposed change is highly urgent, it would still be sensible to resolve the question of whether PEP 517 will be implemented in pip 10 before rushing to implement a partial solution, that by your own admission uses a "proprietary" protocol rather than following PEP 517. Sorry if this isn't the response you were hoping for - but hopefully it explains the situation a little for you. Paul
I'd also note that I've never myself encountered the "horrible easy_install behavior" you mention, and your description doesn't remind me of any specific issues that have been raised. See setuptools issue #917. Setuptools does not use published wheels to fulfill setup_requires, which creates a host of issues when the installed distribution is different to what would have been installed by pip. *All* of the pip developers have very limited time, and complaining that you are being ignored is frankly not the best way of getting attention. I understand that but when I am attempting to use my own time to resolve a serious issue and then no one responded to it, I became suspicious that people were waiting on PEP 517 to resolve the issue. Also, it's important to remember that *no* change will improve things for users until it's in a released version of pip. The next planned version is pip 10, and I for one hope that PEP 517 will be in that version - so why rush in a fix that will only need modifying once PEP 517 is implemented? Precisely because I am highly concerned that PEP 517 does not appear on track to be resolved on distutils-sig before the next release of pip 10. I am more than happy to provide a complete implementation but I cannot proceed until the PEP is accepted. Regards, xoviat From: Paul Moore Sent: Sunday, August 6, 2017 1:58 PM To: 12345 67890 Cc: distutils-sig@python.org Subject: Re: [Distutils] PEP 517 Status On 6 August 2017 at 00:18, 12345 67890 <xoviat@gmail.com> wrote:
I have been attempting to resolve the horrible easy_install behavior where compiled wheels published on pypi are not used to fulfill setup requirements. To address this issue, I have submitted pull requests to both setuptools and pip that would allow a proprietary communication method that can later be easily adjusted to be fully PEP 517 compliant, saving work while resolving a specific issue.
However, everyone appears to be ignoring these pull requests, in my estimation, because PEP 517 is not fully completed. That’s fine, but partial PEP 517 compliance in one area is better than nothing at all, which is currently the default scenario.
That's not correct (at least in my case). I'm "ignoring", as you put it, your PR, because I work on pip in my spare time, and I have extremely limited time to spend on pip, and I'd rather invest my time in other areas. That's my choice, and you complaining about my priorities won't affect it. *All* of the pip developers have very limited time, and complaining that you are being ignored is frankly not the best way of getting attention. To be explicit, I'm currently spending my time on: 1. Mailing list discussions (because I can work on these when not at a PC with a development setup). 2. Triage of issues (explaining misunderstandings, redirecting issues that are actually for other projects, confirming issues are real and requesting PRs, etc) 3. Reviews of PRs where other core pip maintainers or key developers need them. That pretty much uses up all of the time I have available for pip at the moment. I'd also note that I've never myself encountered the "horrible easy_install behavior" you mention, and your description doesn't remind me of any specific issues that have been raised. That's not to say that it's not a significant issue - maybe it is - but if you want to persuade me that it's urgent enough to merit me spending time on it, I'd appreciate links to your PR, and to one or more issues reported against pip explaining how the problem is affecting users. Also, it's important to remember that *no* change will improve things for users until it's in a released version of pip. The next planned version is pip 10, and I for one hope that PEP 517 will be in that version - so why rush in a fix that will only need modifying once PEP 517 is implemented? Even if your proposed change is highly urgent, it would still be sensible to resolve the question of whether PEP 517 will be implemented in pip 10 before rushing to implement a partial solution, that by your own admission uses a "proprietary" protocol rather than following PEP 517. Sorry if this isn't the response you were hoping for - but hopefully it explains the situation a little for you. Paul
participants (2)
-
12345 67890 -
Paul Moore