On 1 Jul 2013 08:40, "Gabriel de Perthuis" <g2p.code@gmail.com> wrote:
On Sun, 30 Jun 2013 21:21:54 +1000, Nick Coghlan wrote:
On 30 June 2013 18:53, Vinay Sajip <vinay_sajip@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