Pub: Allow publishing packages with relative path dependencies contained within the packages being published

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="96" height="96"hspace="10"> Issue by seaneagan
Originally opened as dart-lang/sdk#21920

---

Often when developing a package, you end up developing one or more packages worth of of code within it that you would like to eventually extract into separate packages. Often you are not ready to publish those other packages until you've sufficiently "dogfooded" them within the original package. During this time period it would be awesome if you could still encapsulate those sub-packages so that code in the original package can use "package:" uris e.g. "package:some_sub_package/some_sub_package.dart". Then when you decide to publish one of those sub-packages all you need to do is update your pubspec dependency to a hosted (or git) one, and delete the code from the original package.

Even if you never intend to publish the sub-packages, it would be nice just to be able to encapsulate them to make the "package:uri"s more semantic. It might make transformer usage more sane, and it would facilitate changing the sub-path of the package.

The problem is that pub publish currently disallows all path dependencies. Instead it could validate that all (transitive) path dependencies are specified relatively, and do not escape the root directory of the package being published, or even better "lib", or even better "lib/src". It might even be useful to define a standard sub-directory of "lib/src" where sub packages should be kept, in which case defining a separate package source e.g. "child" or "nested" where you simply specify the name of the child package, and it will look it up in the standard child package directory, but that may or may not be necessary.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

---

I guess you could have the concept of public nested packages as well, but I'm not sure how that's any better than what you can already do with e.g. "package:foo/bar/bar.dart".

[DartBot]

<img src="https://avatars.githubusercontent.com/u/4865287?v=3" align="left" width="48" height="48"hspace="10"> Comment by lrhn

---

Added Area-Pub, Triaged labels.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

---

After a little more thought, putting child packages in "lib/src" is not right. "lib" is for source of code of that packages, so to properly isolate child packages they need to be in a separate top-level directory e.g. "children", "nested", or "pkg". One concrete reason is that the asset environments need to be separated, so this top-level child package directory would need to blacklisted from the parent packages asset environment. This really leans me toward a separate package source when specying child package dependencies e.g. "child" or "nested" (matching the top-level dir name) rather than reusing the "path" package source.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

---

One other motivation for this issue is that the dependencies of the sub-packages can be separated into their own pubspec.yaml. It's often a pain to fish out the sub-package dependencies from the parent pubspec.yaml when you go to extract a child package out.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/405837?v=3" align="left" width="48" height="48"hspace="10"> Comment by zoechi

---

This might be able to help loosen the constraints where currently dependencies for tools, examples, test, and bin, add their constraints also to lib mostly because dev_dependencies also constraint normal dependencies.

See the discussion at https://groups.google.com/a/dartlang.org/d/msg/misc/H-9xOzA59rE/1zAeey1xM30J

[nex3]

Packages are intended as a means of distributing code to other people, not a way of organizing code within a single project. Dart already has a very nice module system that does that well. If your packages are so tightly coupled that they need to be released and consumed together, they shouldn't be distinct packages to begin with.