Pub: Allow publishing packages with relative path dependencies contained within the packages being published #21920
Comments
|
This comment was originally written 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". |
|
This comment was originally written 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. |
|
This comment was originally written 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. |
|
This comment was originally written 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 |
|
This issue has been moved to dart-lang/pub#1218. |
kevmoo
added
type-enhancement
This issue was originally filed by @seaneagan
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 publishcurrently 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.The text was updated successfully, but these errors were encountered: