<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 May 2016 at 15:07, Alex Grönholm <span dir="ltr"><<a href="mailto:alex.gronholm@nextday.fi" target="_blank">alex.gronholm@nextday.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Having setuptools process the setup requirements before parsing
install requirements would be a good step forward. Had that been
done before, we could've just added a setup requirement for a newer
setuptools to enable PEP 508 conditional requirements.<br></div></blockquote><div><br></div><div>Setuptools does process setup requirements before install requirements. The "chicken and egg" issue with setuptools is that, most of the time, setup requires are needed to calculate information that is passed into the `setup()` call itself.</div><div><br></div><div>For example information on header files coming from the C api of `numpy` which is used to build extensions.</div><div><br></div><div>This usually means importing code from the packages in "setup requires" before setuptools has a chance to actually look at it.</div><div><br></div><div>A simple fix would be to allow `setup()` keywords to accept functions as well as direct values and only invoke the functions when the values are actually needed, but this idea never gained traction.</div><div><br></div><div>Of course, even if this was implemented, it wouldn't help directly with "setup requiring" a new version of setuptools itself, unless setuptools detected this situation and reinvoked setup.py from scratch.</div><div><br></div><div>Regards,</div><div><br></div><div>Leo</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>03.05.2016, 21:04, Daniel Holth
kirjoitti:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>We did separate build from install. Now we just want to
be able to build without [having to emulate] distutils; just
having some dependencies installed before setup.py runs
would also be a great boon.</div>
</div>
<div><br>
</div>
<div>I'm reading part of this conversation as "a simple
bdist_wheel bug is a reason to do a lot of work standardizing
file formats" which I find unfortunate.</div>
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">If he is still up for it let
Robert implement his own PEP as the way forward for build
system abstraction. The extra PEPs are just delaying action.</span></div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, May 3, 2016 at 1:11 PM Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank"></a><a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 May
2016 at 17:47, Donald Stufft <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>>
wrote:<br>
> It will likely get decided as part of the build system
PEP, whenever that<br>
> gets picked up again.<br>
<br>
Yes, but on 15th March<br>
(<a href="https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html</a>)<br>
Robert posted<br>
<br>
> Just to set expectations: this whole process seems
stalled to me; I'm<br>
> going to context switch and focus on things that can
move forward.<br>
> Someone please ping me when its relevant to put effort
in again :).<br>
<br>
And I think that's right. The whole build system PEP issue
appears<br>
stalled from a lack of someone willing (or with the time) to
make a<br>
call on the approach we take.<br>
<br>
As far as I'm aware, the decision remains with Nick. With
the possible<br>
exception of Donald's proposal (which AFAIK never got
formally<br>
published as a PEP) everything that can be said on the other
proposals<br>
has been said, and the remaining differences are ones of
choice of<br>
approach rather than anything affecting capabilities.
(Robert's<br>
message at <a href="https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html</a><br>
summarised the state of the 3 proposals at the time).<br>
<br>
I think this is something that should be resolved - we don't
appear to<br>
be gaining anything by waiting, and until we have a decision
on the<br>
approach that's being taken, we aren't going to get anyone
writing<br>
code for their preferred option.<br>
<br>
Nick - do you have the time to pick this up? Or does it need
someone<br>
to step up as BDFL-delegate? Robert, Nathaniel, do you have
time to<br>
spend on a final round of discussion on this, on the
assumption that<br>
the goal will be a final decision at the end of it? Donald,
do you<br>
have the time and interest to complete and publish your
proposal?<br>
<br>
Paul<br>
_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<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/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div></div>