Dev dependencies.

Dev dependencies.
BUG=dartbug.com/5358

Committed: https://code.google.com/p/dart/source/detail?r=19966

[Bob Nystrom, 2013-03-06 22:03:15]

I had a hunch this would be easy to implement so I figured I'd take a stab at
it. Seems to work about right.

Before this goes in, we should discuss whether or not this is the actual
approach we want. We may want something more like groups in Rubygems. Does this
need to coordinate with the idea of dependencies that aren't deployed?

[nweiz, 2013-03-06 22:26:25]

Code changes LGTM. Let's talk about the design in-person.

[kevmoo-old, 2013-03-07 00:30:39]

> Before this goes in, we should discuss whether or not this is the actual
> approach we want. We may want something more like groups in Rubygems. Does
this
> need to coordinate with the idea of dependencies that aren't deployed?

First, love that this is going in.

On the Rubygems comparison, a thought:
Rubygems doesn't have the idea of groups. That's Bundler. Bundler was designed
along side Rails, which has a core notion of environments: production,
development, test, etc--that affect many aspects of a Rails app.

Rubygems at it's core has two kinds of dependencies: runtime and development

http://guides.rubygems.org/specification-reference/#add_development_dependency

I think this aligns really well with Dart and Pub.

Pub special-cases a specific directory: lib.

In this view, devDependecies becomes logically "packages used only by code
outside of lib".

While I can imagine other scenarios and I appreciate the "should we generalize
more?" question, I think adding this one case is perfectly consistent with the
existing model and use case for pub.

[kevmoo-old, 2013-03-07 00:38:53]

Does this  lead to a dart_analyzer feature request?

Something like

--exclude-dev-dependencies pubspec.yaml

So analyzer would use the package-root as it currently exists, but it would
ignore packages that are defined an devDependencies in pubspec

One could then point code analysis at the lib dir and verify the right
dependencies are being used

[Bob Nystrom, 2013-03-13 18:28:39]

On 2013/03/07 00:30:39, kevmoo wrote:
> Pub special-cases a specific directory: lib.
> 
> In this view, devDependecies becomes logically "packages used only by code
> outside of lib".

Yup, that's a good way to think of it.

> While I can imagine other scenarios and I appreciate the "should we generalize
> more?" question, I think adding this one case is perfectly consistent with the
> existing model and use case for pub.

After discussing this with Nathan, I agree too. We may end up with groups at
some point as well, but dev dependencies are worth giving special treatment
since they have special semantics.

[Bob Nystrom, 2013-03-13 18:30:58]

On 2013/03/07 00:38:53, kevmoo wrote:
> Does this  lead to a dart_analyzer feature request?
> 
> Something like
> 
> --exclude-dev-dependencies pubspec.yaml
> 
> So analyzer would use the package-root as it currently exists, but it would
> ignore packages that are defined an devDependencies in pubspec
> 
> One could then point code analysis at the lib dir and verify the right
> dependencies are being used

This is a good point. Something along these lines could be useful. Otherwise,
you can specify a dev dependency, inadvertently import it from something in lib/
and then break anyone who tries to use your package.

(Of course, pub also has a similar problem in that you can import a transitive
dependency, and you'll break your package if the chain that led to that
transitive dep stops relying on it.)

I think we should have a warning in the editor/analyzer that:

1. Yells at you if you have a "package:" import for a package that isn't in your
pubspec.
2. Yells at you if you have a "package:" import in lib/ for a package that isn't
in your pubspec's non-dev dependencies section.

[Bob Nystrom, 2013-03-13 18:31:42]

As per our discussion:

* Make it fail if you have a package collision between deps and dev deps.
* Rename the pubspec field to "dev_dependencies".

PTAL!

[nweiz, 2013-03-13 18:46:29]

One suggestion, otherwise LGTM.

https://codereview.chromium.org/12433014/diff/3001/utils/pub/pubspec.dart
File utils/pub/pubspec.dart (right):

https://codereview.chromium.org/12433014/diff/3001/utils/pub/pubspec.dart#new...
utils/pub/pubspec.dart:124: 'and "dev_dependencies".');
Let's list all the collisions so users don't have to run commands over and over
again.

[Bob Nystrom, 2013-03-13 19:40:40]

Committed patchset #3 manually as r19966 (presubmit successful).

[Bob Nystrom, 2013-03-13 19:42:25]

Thanks!

[Bob Nystrom, 2013-03-13 19:42:44]

https://codereview.chromium.org/12433014/diff/3001/utils/pub/pubspec.dart
File utils/pub/pubspec.dart (right):

https://codereview.chromium.org/12433014/diff/3001/utils/pub/pubspec.dart#new...
utils/pub/pubspec.dart:124: 'and "dev_dependencies".');
On 2013/03/13 18:46:29, nweiz wrote:
> Let's list all the collisions so users don't have to run commands over and
over
> again.

Done.