This comment has been minimized.

edited

@oiooj , the issue is that vgo build does not generate any go.mod file that I can modify manually. What I am expecting as an user is vgo build automatically does that for me, since all necessary information is already there.

This comment has been minimized.

vgo build could replicate the replacements from your glide.lock locally as replace directives, but that wouldn't work for other modules that import your (non-main) packages: by design¹, replace directives only apply locally.

It seems that in order for this repository to be compatible with vgo, you will need to rewrite the imports to point to the forks directly.

This closely relates to one of the examples in Part 9 of @rsc's blog series:

As another example, Go import paths are URLs. If code said import "uuid", you’d have to ask which uuid package. Searching for uuid on godoc.org turns up dozens of packages. If instead the code says import "github.com/pborman/uuid", now it’s clear which package we mean. Using URLs avoids ambiguity and also reuses an existing mechanism for giving out names, making it simpler and easier to coordinate with other programmers.

This comment has been minimized.

That said, it does seem like vgo build could be more error-tolerant: it could ignore errors for unresolvable packages and write out the rest of the go.mod file.

It seems likely that you'd still need to rewrite the imports in order for vgo to be able to build the module, so I'm not sure whether that level of error-tolerance is really any help: it would change the sequence of operations, but wouldn't save you any work overall.

bcmills
changed the title
x/vgo: build fails on repos that use forksx/vgo: build fails to generate go.mod from a glide.lock that uses forksMay 31, 2018

…lude statement
Now modconv is only work with the basic cases, we need support
"replace" and "exclude" from legacy config.
In followup CLs, It will preserve replacements from glide and vendor.json.
Updates golang/go#25556
Updates golang/go#24087
Change-Id: Ie5ca8df7f685177afea9cc7affcc6240b38223b5
Reviewed-on: https://go-review.googlesource.com/120075
Reviewed-by: Russ Cox <rsc@golang.org>

rsc
changed the title
cmd/go: conversion does not preserve replacements from dep, glide, govendorcmd/go: conversion does not preserve replacements from dep, glide, govendor, etcAug 10, 2018

This comment has been minimized.

@tamalsaha It reads glide.lock, not glide.yaml. It doesn't have the lines for apimachinery because it doesn't convert replacements (the hashes listed in glide.lock don't exist in the main repos). If we started converting replacements (and first understood exactly what that meant, which we don't quite), then more might work. But I'm glad you are getting a go.mod now.

This comment has been minimized.

vgo build could replicate the replacements from your glide.lock locally as replace directives, but that wouldn't work for other modules that import your (non-main) packages: by design¹, replace directives only apply locally.

It seems that in order for this repository to be compatible with vgo, you will need to rewrite the imports to point to the forks directly.

I have a fork of x/net with some fixes, and I use glide.lock to ensure my fork is used by all of my other dependencies. Is there any way of achieving this with vgo, short of forking each of my dependencies that may be using x/net and search/replacing their imports?