<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 March 2017 at 14:17, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On 11 March 2017 at 07:03, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr" class="gmail-m_-6127580605688701850gmail-m_289809493005807332gmail_msg">You lost me a bit at 'extra sets'. FYI it is already possible to depend on your own extras in another extra.</div><div dir="ltr" class="gmail-m_-6127580605688701850gmail-m_289809493005807332gmail_msg"><br></div><div class="gmail-m_-6127580605688701850gmail-m_289809493005807332gmail_msg">Extra pseudo code:</div><div dir="ltr" class="gmail-m_-6127580605688701850gmail-m_289809493005807332gmail_msg">spampackage</div><div class="gmail-m_-6127580605688701850gmail-m_289809493005807332gmail_msg">extra['spam'] = 'spampackage[eggs]'</div><div class="gmail-m_-6127580605688701850gmail-m_289809493005807332gmail_msg">extra['eggs'] = ...</div></div></blockquote></span><div><br><div class="gmail_quote">Oh, nice. In
 that case, we can drop the '*' idea and just make "all" another 
pre-declared extra with a SHOULD that says sdist build tools should 
implicitly populate it as:<br><br>    {<br></div><div class="gmail_quote">        "requires": "thisproject[extra1,extra2,<wbr>extra3,extra4]"<br></div><div class="gmail_quote">        "extra": "all"<br></div><div class="gmail_quote">    }<br><br></div><div class="gmail_quote">given an extras clause containing '["extra1",'extra2","extra3","<wbr>extra4"]'.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Endorsing
 that approach to handling "extra sets" does impose a design constraint 
though, which is that installation tools will need to special-case 
self-referential requirements so they don't get stuck in a recursive 
loop. (That will become a new MUST in the spec)<br></div></div></div></div></div></blockquote><div><br></div><div>Next update: <a href="https://github.com/python/peps/commit/24cd02b34cea1bf35443048fd665485dffd0de93">https://github.com/python/peps/commit/24cd02b34cea1bf35443048fd665485dffd0de93</a><br><br></div><div>- metadata version bumped to 3.0<br></div><div>- expected filename changed to pysdist.json and stated to be immutable once generated for a given release<br></div><div>- project obsolescence changes deferred to a possible future metadata extension<br></div><div>- no proposed changes to extras syntax and the "self" and "runtime" pseudo-extras dropped<br></div><div>- "all" added as an implied extra for all declared extras<br></div><div>- "alldev" added as an implied superset of "test", "build", "doc" and "dev"<br><br></div><div>Even though it's not strictly necessary, I'd still kind of like to have a standard way to say "install all the dev dependencies, but not the package itself or its runtime dependencies". I guess if we take distro build tools as an example though, they handle that as a separate command (e.g. "dnf builddep" vs "dnf install") rather than as a variation on the normal install command.<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br></div></div><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>