support or complain if `pub run my_bin_script` depends on dev-dependencies

[sigmundch]

This feature request summarizes a discussion Natalie, Kevin, and I had last week.

Most people are surprised if in package a you do:

  pub run foo

and it works, but when running it in package b, as:

  pub run a:foo

it fails.

This typically happens if foo uses code from dev_dependencies.

This feature request is to make pub run foo work the same everywhere. We discussed several ideas for how to do this:

a) make pub-run/pub-get use the dev-dependencies of package a and when executing foo:a.

b) like (a), but to keep things cleaner we could add a third dependency section: bin_dependencies (since dev_dependencies are really just for developers of the package).

c) force using just dependencies and not dev_dependencies when executing in pub-run. This will make pub run foo fail locally and users will realize that they need to change a dev_dependency as a normal dependency.

Our conclusions were that probably (c) is the simplest. But (b) might reduce the number of false-positives for version conflicts - if a tool in bin/ uses a dependency but it doesn't require it to be the same that is used in the library of another package, then there is no conflict. Those two pieces of code will never be able to depend on each other anyways.

[nex3]

I strongly prefer (c). I don't like the idea of adding more kinds of dependencies, and in practice bin_dependencies would be installed more or less any time normal dependencies are—there's no way for pub to know whether the end user intends to use the executables, so it would have to be conservative and assume they do.

[munificent]

a) make pub-run/pub-get use the dev-dependencies of package a and when executing foo:a.

This won't work for lots of version-solving shenanigans I won't get into. Even if it did work, it might have unintented consequences: running foo:a in the context of your app may use a different version of some shared dependency that your app itself uses.

b) like (a), but to keep things cleaner we could add a third dependency section: bin_dependencies (since dev_dependencies are really just for developers of the package).

The core problem is users are erroneously putting some deps in the wrong bucket (dev instead of regular), so I don't think adding a third bucket will make this less likely.

This error is common because up until very very recently, dev_deps worked fine for stuff in bin, and, in fact, I don't think we ever gave guidance one way or the other. There's been no negative repercussions of making this mistake until recently. Now that there is, I think people will learn the right way.

c) force using just dependencies and not dev_dependencies when executing in pub-run. This will make pub run foo fail locally and users will realize that they need to change a dev_dependency as a normal dependency.

Neat idea. However, it gets a bit confusing when you consider things like 'pub run test/some_test'. That obviously should include dev deps. We could only do this for executables in bin, but I'm hesitant to add special-case logic users will end up needing to know.

It's worth noting that the analogous problem exists for stuff in lib/. You can have a library in lib/ import something from a dev dep. If you run your tests or examples in your package, it works fine. But if anyone else tries to use your library... failure.

We've talked about providing some validation for this, but, in practice, it hasn't been a very common issue. In think stuff in bin/ will be in the same boat once people have had some time to get educated.

[nex3]

I don't think we ever gave guidance one way or the other.

I think we did, it was just quiet and not backed up by real repercussions.

We've talked about providing some validation for this, but, in practice, it hasn't been a very common issue. In think stuff in bin/ will be in the same boat once people have had some time to get educated.

Maybe the best way to handle this would be with a validation step on publish. When we first wrote those, we didn't have the technology to parse imports, but we do now; being able to say "this public library (in bin or lib) imports a dev dependency" could be generally useful.

[kevmoo]

+1 for validating on publish. A great idea.

[DartBot]

This comment was originally written by @seaneagan

---

I just noticed this issue after filing issue #22054.

The idea I had with bin_dependencies was to have pub get yield two separate dependency graphs e.g. packages and bin_packages. pub publish could validate that code outside bin (and possibly tool?) doesn't use any bin_dependencies.

We can move any further discussions on bin_dependencies over to issue #22054.

[DartBot]

This issue has been moved to dart-lang/pub#1134.