Updating the docs on subpackages #431
Conversation
| @@ -41,6 +41,7 @@ These elements are: | |||
| - `version`: A semantic version, semantic version range, branch, tag, or commit id to use. For more information see the [versioning documentation](versions.md). | |||
| - `repo`: If the package name isn't the repo location or this is a private repository it can go here. The package will be checked out from the repo and put where the package name specifies. This allows using forks. | |||
| - `vcs`: A VCS to use such as git, hg, bzr, or svn. This is only needed when the type cannot be detected from the name. For example, a repo ending in .git or on GitHub can be detected to be Git. For a repo on Bitbucket we can contact the API to discover the type. | |||
| - `subpackages`: A record of packages being used within a repository. This does not include all packages within a repository but rather those being used. | |||
There was a problem hiding this comment.
Could we have a note to say why we might care. As I understand it it is prevent all the (transitive) dependencies being fetched for a package within a repo that you don't use. Is that all?
There was a problem hiding this comment.
@silasdavis There is not as much of a reason to have it as there used to be. This was far more important prior to the code scanning we have now.
This is useful in the lock files because other tools can use that information such as glide-vc.
|
@mattfarina I left a comment on #430 about the future of subpackages; I understand that their original purpose has fallen by the wayside, but there's an itch that's left unscratched, relating to versioning the binaries that one |
No description provided.