Perhaps we should hard-code a rule (make it a cross-language industry standard) that says that the dependencies of a module should always be listed with the module (in a fixed format) and the build system doesn't allow the use of anything else (as a verification step).
That way, we could have a tool that always correctly shows the dependencies between modules.
While we're at it, build semantic versioning into the package repository. For instance, if you push a version 1.1.3 that has a different API than version 1.1.2, the repository should just outright deny the push and require you to publish this as version 1.2.0. It's a little annoying on the part of the library author, but would make all consumers of the library much more confident in upgrading.
Comments
Perhaps we should hard-code a rule (make it a cross-language industry standard) that says that the dependencies of a module should always be listed with the module (in a fixed format) and the build system doesn't allow the use of anything else (as a verification step).
That way, we could have a tool that always correctly shows the dependencies between modules.
While we're at it, build semantic versioning into the package repository. For instance, if you push a version 1.1.3 that has a different API than version 1.1.2, the repository should just outright deny the push and require you to publish this as version 1.2.0. It's a little annoying on the part of the library author, but would make all consumers of the library much more confident in upgrading.