<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
As I pointed out in my previous post, "extended commands" are not
the only use case for setup_requires -- upgrading setuptools itself
would enable support for PEP 508 style conditional requirements.
This currently does not work because if you have such requirements
in your setup(), setuptools will fail when parsing those before it
even has a chance to act on the minimum setuptools requirement
specification in setup_requires.<br>
<br>
<div class="moz-cite-prefix">03.05.2016, 21:33, Daniel Holth
kirjoitti:<br>
</div>
<blockquote
cite="mid:CAG8k2+7ybZEgkcYnn5W_Vz5LffrNjuN7KsQyqK3gN9SL1ixKHA@mail.gmail.com"
type="cite">
<div dir="ltr">What happened is that only a half-dozen setuptools
experts (I am not one of those six people) know how to write an
extended command or whatever that would actually be able to take
advantage of setup requirements as implemented by setuptools.
Everyone else wants to "import x" at the top of setup.py and
pass arguments to the setup() function. So it would be better to
have the installer make that possible.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, May 3, 2016 at 2:29 PM Alex Grönholm <<a
moz-do-not-send="true"
href="mailto:alex.gronholm@nextday.fi"><a class="moz-txt-link-abbreviated" href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a></a>>
wrote:<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"> No, setuptools parses
the install requirements before acting on setup
requirements. That is the source of the problem. If
setuptools only parsed and acted on setup requirements
before even parsing install requirements, this wouldn't be
an issue.</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>03.05.2016, 21:26, Leonardo Rochael Almeida kirjoitti:<br>
</div>
<blockquote type="cite">
<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
moz-do-not-send="true"
href="mailto:alex.gronholm@nextday.fi"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a></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
moz-do-not-send="true"
href="mailto:p.f.moore@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a></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
moz-do-not-send="true"
href="mailto:donald@stufft.io"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:donald@stufft.io">donald@stufft.io</a></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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:Distutils-SIG@python.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a></a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a moz-do-not-send="true" 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
moz-do-not-send="true"
href="mailto:Distutils-SIG@python.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a></a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</div>
_______________________________________________<br>
Distutils-SIG maillist - <a moz-do-not-send="true"
href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>