Allow missing source annotations for path deps

[djkoloski]

Fixes #1631. Missing source annotations are expected when providing local packages or patching crates that would be vendored.

[UebelAndre]

Fixes #1631. Missing source annotations are expected when providing local packages or patching crates that would be vendored.

Is there a way to make this more explicit? In general I think that path packages are a hard thing to support correctly but agree that they can be very useful for this [patch] case. Would it be possible to create a concrete representation for path packages and ensure they're paths within the repo itself? If this functionality is also available to crates_repository then I think there needs to be a way to properly track the manifests at the given path by the repository rule.

[djkoloski]

We could try parsing the id field of each package. That contains information about the path to the crate, eg:

"id": "zerocopy 0.6.1 (path+file:///path/to/zerocopy)"

It's worth noting that although the id field contains this information about a local path, there is a warning in the documentation that the format of the id field may change at any time. The information in id doesn't appear in the source field, which is always None for path dependencies. I don't think there's any other way to reliably tell path dependencies from other dependencies.

[UebelAndre]

there is a warning in the documentation that the format of the id field may change at any time.

Do you have a link to this? I care most that the case of something being a path dependency is clear but if it can be explicitly represented (even by some internal container) that'd be great. Can you also provide some kind of end to end test for this change? I'm really concerned about introducing any support for paths since I think it could lead to really confusing issues down the road where people start using relative paths outside the workspace.

[djkoloski]

Do you have a link to this?

The documentation for the output of cargo metadata does not specify any particular format for the id. This is supported by the documentation for PackageId field in the cargo-metadata crate. So we could technically parse this to get the information we need but should be prepared to take on a maintenance burden if it changes.

Can you also provide some kind of end to end test for this change?

Sure, those are all in tests right? I just have to read up a bit more so I know how to set it up.

I'm really concerned about introducing any support for paths since I think it could lead to really confusing issues down the road where people start using relative paths outside the workspace.

The only goal of this change is to fix #1631, so if there's another approach that would work and you like better then I'm more than happy to pursue that instead.

[djkoloski]

We also have the manifest path in the manifest_path field. Maybe we could check the source field and fall back to the manifest path?

[andrewpollack]

Are there any updates on this?

[herry-c]

I have a similar problem. Is there any other way to use [patch] through bazel?

[shelbyd]

I've been able to get past the no source info error by forking the patched dependency and patching with a git = "..." specification. While I'd prefer to include the vendored dependencies in the same repo, in a third_party/ dir, it's workable for me to have a github.com/<my-company>/<my-project>-vendored repo.

[UebelAndre]

Can you add some unit testing for this?

[djkoloski]

Closing this PR, the work for this has been incorporated into #1902.