<p dir="ltr"><br>
On 1 Jul 2013 08:40, "Gabriel de Perthuis" <<a href="mailto:g2p.code@gmail.com">g2p.code@gmail.com</a>> wrote:<br>
><br>
> On Sun, 30 Jun 2013 21:21:54 +1000, Nick Coghlan wrote:<br>
> > On 30 June 2013 18:53, Vinay Sajip <<a href="mailto:vinay_sajip@yahoo.co.uk">vinay_sajip@yahoo.co.uk</a>> wrote:<br>
> >> Nick Coghlan <ncoghlan <at> <a href="http://gmail.com">gmail.com</a>> writes:<br>
> >><br>
> >>> No, because the semantic dependencies form a Cartesian product with<br>
> >>> the extras. You can define :meta:, :run:, :test:, :build: and :dev:<br>
> >>> dependencies for any extra. So if, for example, you have a "localweb"<br>
> >>> extra, then you can define extra test dependencies for that.<br>
> >>><br>
> >>> The semantic specifiers determine *which sets of dependencies* you're<br>
> >>> interested in, while the explicit extras define optional subsets of<br>
> >>> those.<br>
> >><br>
> >> Isn't that the same as having an additional field in the dependency mapping?<br>
> >> It seems like that's how one would organise it at the RDBMS level, anyway.<br>
> >><br>
> >> {<br>
> >>   "install": "localweb-test-util [win] (>= 1.0)",<br>
> >>   "extra": "localweb",<br>
> >>   "environment": "sys_platform == 'win32'",<br>
> >>   "kind": ":test:"<br>
> >> }<br>
> ><br>
> > You certainly *could* define it like that, but no existing dependency<br>
> > system I'm aware of does it that way. If they allow for anything other<br>
> > than runtime dependencies in the first place, they define a different<br>
> > top level field:<br>
> ><br>
> > * setuptools has requires and install_requires<br>
> > * PEP 346 has Requires-Dist and Setup-Requires-Dist<br>
> > * RPM has Requires and BuildRequires<br>
> > * npm has dependencies and devDependencies<br>
><br>
> At least for Debian, and probably RPM, source dependencies have a<br>
> different field name because they are carried by a source package<br>
> rather than a binary one.  The nature of the dependencies isn't<br>
> different, the required packages are binary in both cases.<br>
><br>
> The cartesian product might be overkill.  If someone elects to install<br>
> development dependencies I don't see a point in picking and choosing.<br>
> There's enough support noise when people fail to build from source,<br>
> and while an author is knowledgeable and might conceive more than one<br>
> way to set things up, publishing them would cause more trouble than<br>
> it's worth.</p>
<p dir="ltr">I've had to port stuff to build on s390s - it would have made my life much easier if the dependencies that were only needed for optional x86_64 specific C accelerators had been clearly marked, rather than my having to weed them out through trial and error.</p>

<p dir="ltr">What you're talking about is a rationale for sensible defaults and helper commands in tools (and the PEP does go into that), but it's not a good reason to limit the expressiveness of the format itself.</p>

<p dir="ltr">><br>
> So it would prefer that dev and test be extras with well known names,<br>
> so that dev, test, an any other extras define dependencies with a<br>
> minimum of ambiguity and without the need for a second level of<br>
> qualifiers.</p>
<p dir="ltr">How would you express an optional dependency on Cython for optional C accelerators in such a system?</p>
<p dir="ltr">The PEP is as it is because I think the payoff in expressiveness is worth the increase in complexity. Saying "You shouldn't want to describe such situations clearly and succinctly" is not a compelling argument.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>