<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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_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_289809493005807332gmail_msg"><br></div><div class="gmail-m_289809493005807332gmail_msg">Extra pseudo code:</div><div dir="ltr" class="gmail-m_289809493005807332gmail_msg">spampackage</div><div class="gmail-m_289809493005807332gmail_msg">extra['spam'] = 'spampackage[eggs]'</div><div class="gmail-m_289809493005807332gmail_msg">extra['eggs'] = ...</div></div></blockquote><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,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","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><br></div>That just leaves the 
question of how to install build & test requirements without 
installing the project itself, and I guess we don't actually need to 
handle that at the Python metadata level - it can be done by external 
tools. For example, in the pyp2rpm case, it's handled by the translation
 to BuildRequires and Requires terms at the RPM level, with RPM then 
handling the task of setting up the build environment correctly.<br> <br></div><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_289809493005807332gmail_msg"><div class="gmail-m_289809493005807332gmail_msg"></div><div class="gmail-m_289809493005807332gmail_msg">+1 on extras. The extras feature has the wonderful property that people understand it. Lots of projects have a 'test' extra instead of tests_require for example, and you don't have to look up how to install them.</div></div></div></blockquote><div><br></div><div>Yeah, it was really helpful to me to work through the "How would I replace this proposal with the existing extras system?", since the end result achieved everything I was aiming for without requiring any fundamentally new concepts or tech.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,<br></div><div class="gmail_quote">Nick.<br></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>