On 1 Jul 2013 08:40, "Gabriel de Perthuis" <g2p.c...@gmail.com> wrote:
>
> On Sun, 30 Jun 2013 21:21:54 +1000, Nick Coghlan wrote:
> > On 30 June 2013 18:53, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> >> Nick Coghlan <ncoghlan <at> gmail.com> writes:
> >>
> >>> No, because the semantic dependencies form a Cartesian product with
> >>> the extras. You can define :meta:, :run:, :test:, :build: and :dev:
> >>> dependencies for any extra. So if, for example, you have a "localweb"
> >>> extra, then you can define extra test dependencies for that.
> >>>
> >>> The semantic specifiers determine *which sets of dependencies* you're
> >>> interested in, while the explicit extras define optional subsets of
> >>> those.
> >>
> >> Isn't that the same as having an additional field in the dependency
mapping?
> >> It seems like that's how one would organise it at the RDBMS level,
anyway.
> >>
> >> {
> >> "install": "localweb-test-util [win] (>= 1.0)",
> >> "extra": "localweb",
> >> "environment": "sys_platform == 'win32'",
> >> "kind": ":test:"
> >> }
> >
> > You certainly *could* define it like that, but no existing dependency
> > system I'm aware of does it that way. If they allow for anything other
> > than runtime dependencies in the first place, they define a different
> > top level field:
> >
> > * setuptools has requires and install_requires
> > * PEP 346 has Requires-Dist and Setup-Requires-Dist
> > * RPM has Requires and BuildRequires
> > * npm has dependencies and devDependencies
>
> At least for Debian, and probably RPM, source dependencies have a
> different field name because they are carried by a source package
> rather than a binary one. The nature of the dependencies isn't
> different, the required packages are binary in both cases.
>
> The cartesian product might be overkill. If someone elects to install
> development dependencies I don't see a point in picking and choosing.
> There's enough support noise when people fail to build from source,
> and while an author is knowledgeable and might conceive more than one
> way to set things up, publishing them would cause more trouble than
> it's worth.
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.
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.
>
> So it would prefer that dev and test be extras with well known names,
> so that dev, test, an any other extras define dependencies with a
> minimum of ambiguity and without the need for a second level of
> qualifiers.
How would you express an optional dependency on Cython for optional C
accelerators in such a system?
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.
Cheers,
Nick.
>
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
