Add support for specifying the sub-directory of a git repository for forc
dependencies
#953
Labels
bikeshedding
For bikeshedding trivialities
forc
forc-pkg
Everything related to the `forc-pkg` crate.
Implementing #952 should get us support for dependencies in git repository sub-directories.
However as mentioned in that issue, the approach of walking the entire repo may take a long time for large mono-repo projects or cause issues if there is more than one project with the same name for whatever reason.
We should optionally allow the user to specify a particular sub-directory to avoid performing the search if they wish.
E.g. if we have a repository at
github.com/owner/repo
that has 2 sway libraries in it calledfoo
andbar
under respective directories, we should allow for specifying them like so:We might want to bikeshed over what field to use to declare this subpath, as using
path
might be a little contentious seeing as the same field is already used to describe local dependencies.Further, in cargo, specifying both
path
andgit
for a dependency used to have a different meaning, wherepath
would be relative to the manifest and would overridegit
. I believe this was originally supported in order to allow for a very basic approach of "patching" a top-level dependency for testing. Since then,[replace]
was introduced as the proper approach to patching, then it was replaced by[patch]
, and then finally specifying bothpath
andgit
simultaneously was deprecated in 2018.My proposal is to update the meaning of the
path
field to the following with some clear documentation while we still have a fresh slate:git
repository is specified,path
is relative to the root of the repository.git
repository is specified,path
is relative to the project's manifest.The text was updated successfully, but these errors were encountered: