Special case vbom.ml packages. Fixes #1169

[redbaron]

What does this do / why do we need it?

Special case root and source deducing for vbom.ml/util package

Which issue(s) does this PR fix?

fixes #1169

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[redbaron]

signed

[googlebot]

CLAs look good, thanks!

[sdboyer]

i'm sorry, but we do not add special deduction cases for personal aliases. this is what running a go get metadata service is for.

[redbaron]

Fair enough, but what if go get metadata is unavailable/not present? Is there manual workaround one can do to pull project? Worst bit is that this is a transitive dependency I am trying to make work :(

[sdboyer]

if the go get metadata isn't present to go along with a given import path, then basically, that import path is broken. 😢

Worst bit is that this is a transitive dependency I am trying to make work :(

uuuuugghhhh, yeah. i wish people wouldn't use these cutesy personalized imports without understanding the runtime dependencies they're imposing on the ecosystem, all the way up the chain.

basically, i'd file a PR against the dep that's relying on that project and ask them to repoint their import paths. in the meantime, point your dependency on the intermediary to your fork with the corrected import path using a source directive in Gopkg.toml.

[redbaron]

@sdboyer , failure happens in deduceRoot which uses just import name as an input, therefore source from Gopkg.toml is not used. Would you accept patch where Gopkg.toml is consulted and if import being resolved is found among constraints[].name then it is used as root and source from that section is used as a result of deduceSource?

[sdboyer]

i was recommending that you specify an alternate source for the dependency that imports vbom.ml/util, not for vbom.ml/util itself, because of the problem you highlight.

a change to accomplish what you're outlining is possible, but is actually rather complicated to implement, as it entails changes in the solver itself - see #860.