[prev in list] [next in list] [prev in thread] [next in thread]
List: python-distutils-sig
Subject: Re: [Distutils] PEP 517 again
From: Chris Barker - NOAA Federal <chris.barker () noaa ! gov>
Date: 2017-08-31 22:49:01
Message-ID: 9102857541681617612 () unknownmsgid
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
One thing to keep in mind is that there are quite a few projects on pypa
with pure python source distributions uploaded that will not be updated and
people may still desire to use. We want pip to be able to still build and
install them.
That is the challenge!
But the motivating use case here was a package with a c extension that was
optionally built.
That's the rare case.
Regular old pure-python packages are the usual case, and a lot easier.
-CHB
2017-08-31 16:29 GMT-05:00 Chris Barker <chris.barker@noaa.gov>:
> On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith <njs@pobox.com> wrote:
>
>> > Surely the build system should know how to correctly name the wheel it
>> builds.
>>
>> It's probably worth mentioning the specific problem that motivated pip
>> to start doing this.
>>
>> It used to be standard, and is still quite common, for setup.py
>> scripts to contain stuff like:
>>
>> install_requires = [...]
>> if sys.version_info < (3, 4):
>> install_requires += [...]
>> if platform.python_implementation() == "PyPy":
>> install_requires += [...]
>>
>> setup(..., install_requires=install_requires)
>>
>> This kind of logic in setup.py worked fine in the old days when all
>> you did was 'setup.py install', but then wheels came along
>
>
> And indeed, setuptools originally used easy_install, which was part of
> setuptools...
>
> and
>> retroactively turned lots of setup.py scripts from working into
>> broken. The problem is that with this kind of setup.py,
>>
>
>
>> But it will take a while for existing setup.py files transition to
>> using those, and in the mean time pip can't assume that a random wheel
>> generated by 'setup.py bdist_wheel' has accurate Python tags.
>>
>
> This was my original point -- I understand that we want "pip install" to
> continue to work for, hopefully, everything it works for now.
>
> But I do think we should be clear about what is a hack for backward
> compatibility, and what is part of the designed functionality.
>
> Sorry to be poking at all this from the fringes (Not having been all that
> involved in a very long discussion), it's just that the whole
>
> distutils--setuptools--pip--distribute--setuptools--pip
>
> stack has a LOT of legacy cruft, and I'm concerned that the efforts for
> backward compatibility may end up leading us to another poorly de-coupled
> design.
>
>
>> Hopefully new legacy-free backends will get this right from the start.
>>
>
> exactly -- let's keep the "backward compatibility hack" labels clear!
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker@noaa.gov
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
[Attachment #5 (text/html)]
<html><head><meta http-equiv="content-type" content="text/html; \
charset=utf-8"></head><body dir="auto"><div><br></div><blockquote \
type="cite"><div><div dir="ltr"><div>One thing to keep in mind is that there are \
quite a few projects on pypa with pure python source distributions uploaded that will \
not be updated and people may still desire to use. We want pip to be able to still \
build and install them.</div></div></div></blockquote><div><br></div><div>That is the \
challenge!</div><div><br></div><div>But the motivating use case here was a package \
with a c extension that was optionally built. </div><div><br></div><div>That's \
the rare case.</div><div><br></div><div>Regular old pure-python packages are the \
usual case, and a lot \
easier.</div><div><br></div><div>-CHB</div><div><br></div><blockquote \
type="cite"><div><div class="gmail_extra"><div class="gmail_quote">2017-08-31 16:29 \
GMT-05:00 Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" \
target="_blank">chris.barker@noaa.gov</a>></span>:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><span class="">On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith \
<span dir="ltr"><<a href="mailto:njs@pobox.com" \
target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span>> Surely the build system should know how to \
correctly name the wheel it builds.<br> <br>
</span>It's probably worth mentioning the specific problem that motivated pip<br>
to start doing this.<br>
<br>
It used to be standard, and is still quite common, for setup.py<br>
scripts to contain stuff like:<br>
<br>
install_requires = [...]<br>
if sys.version_info < (3, 4):<br>
install_requires += [...]<br>
if platform.python_implementation<wbr>() == "PyPy":<br>
install_requires += [...]<br>
<br>
setup(..., install_requires=install_requi<wbr>res)<br>
<br>
This kind of logic in setup.py worked fine in the old days when all<br>
you did was 'setup.py install', but then wheels came \
along</blockquote><div><br></div></span><div>And indeed, setuptools originally used \
easy_install, which was part of setuptools...</div><span \
class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">and<br> retroactively turned lots \
of setup.py scripts from working into<br> broken. The problem is that with this kind \
of setup.py, <br></blockquote><div> </div></span><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But it will \
take a while for existing setup.py files transition to<span class=""><br> using \
those, and in the mean time pip can't assume that a random wheel<br> generated by \
'setup.py bdist_wheel' has accurate Python \
tags.<br></span></blockquote><div><br></div><div>This was my original point -- I \
understand that we want "pip install" to continue to work for, hopefully, \
everything it works for now.</div><div><br></div><div>But I do think we should be \
clear about what is a hack for backward compatibility, and what is part of the \
designed functionality.</div><div><br></div><div>Sorry to be poking at all this from \
the fringes (Not having been all that involved in a very long discussion), it's \
just that the whole</div><div><br></div><div>distutils--setuptools--pip--<wbr>distribute--setuptools--pip</div><div><br></div><div>stack \
has a LOT of legacy cruft, and I'm concerned that the efforts for backward \
compatibility may end up leading us to another poorly de-coupled design.</div><span \
class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Hopefully new legacy-free backends \
will get this right from the \
start.<br></blockquote><div><br></div></span><div>exactly -- let's keep the \
"backward compatibility hack" labels \
clear!</div><div><br></div><div>-CHB</div></div><span class=""><br \
clear="all"><div><br></div>-- <br><div class="m_-5013071504679899711gmail_signature" \
data-smartmail="gmail_signature"><br>Christopher Barker, \
Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R \
<a href="tel:(206)%20526-6959" value="+12065266959" target="_blank">(206) \
526-6959</a> voice<br>7600 Sand Point Way NE <a href="tel:(206)%20526-6329" \
value="+12065266329" target="_blank">(206) 526-6329</a> fax<br>Seattle, WA \
98115 <a href="tel:(206)%20526-6317" value="+12065266317" \
target="_blank">(206) 526-6317</a> main reception<br><br><a \
href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div> \
</span></div></div> <br>______________________________<wbr>_________________<br>
Distutils-SIG maillist - <a \
href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br> <a \
href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" \
target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br> \
<br></blockquote></div><br></div> </div></blockquote></body></html>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic