Awesome to see this moving forward!
Thanks for all the hard work.
Minor item: the document has a few question marks throughout (I counted
three) that aren't captured in open questions.
The glossary says: "the unit of dependency is the repository, not the
package." This totally makes sense to me for DVCS, but is confusing to
me with respect to centralized servers (i.e. Subversion) that can
combine many projects - versioned in a unrelated way - into a single
repository. With centralized servers, this definition doesn't really
help. I suspect there's common understanding of this situation, but
perhaps the glossary just isn't clear? I checked the use-cases and
didn't see anything that covered this.
" alternate network source location" - Seems like this could be an
optional field for dependencies and overrides, but that's not written
here. That is, the import name + version may be sufficient to identify
network location, so "alternate network source" is optional. Also, long
term, it strikes me that there's some value in a layer of indirection. A
company might want to set up an internal repository of external
projects, so that reproducible builds use a corporate controlled
repository (US14). Do you intend here that the manifest identify the
direct location to the internal clone of external repository, or does
this mean a "root" location under which the package can be found.
License information is mentioned in the features document, but isn't
called out in the manifest. Licensing also not mentioned in use cases.
Is this over-reach in the features document, or an oversight for the spec?
The assumption: "The project builds and works as intended with the
current GOPATH and/or vendored dependencies" - this fits the use case of
building a main application, but not so well for a library. In order for
libraries to build /test against multiple versions of dependencies,
vendoring dependencies is awkward at best, and in the alternate, cannot
possibly cannot all live on the same GOPATH. I've puzzled over this, and
think I've hit on a possible solution, outlined below.
Another assumption: "A VCS is initialized for the project (eg "git
init")." I think this means that the tool must assume that the source of
the project is already under version control, not that dep init will
also run "git init". The wording here confused me.
" Look for a VCS metadata directory, from the current directory upwards"
- does this work for all known VCSes? I seem to recall Perforce storing
data about project roots somewhere other than the project directory, but
maybe they do it differently now? Been a long time since I used Perforce
Status, fetch/update, remove
I suspect it would be extremely useful for downstream tooling (IDEs,
etc.) if dep status et. al. took an option to return machine readable
format - something like "-json". Probably something that can be punted
for future versions. Perhaps worth calling out for "not addressed" section?
Thanks so much for all the hard work trying to get this resolved!
Proposed concept for not vendoring dependencies, but enabling multiple
Assumption stated in "init" process is that everything builds with
current GOPATH and/or vendored dependencies. I don't see how I can make
this work if I want to test my library against multiple versions of a
dependency. (Example, two different versions of github.com/foobar/baz
I can't vendor both versions in my repo, and I can't put both versions
on the GOPATH either (since the whole point is that they share the same
name import name, but are of different versions). I see only two
solutions - either forcing developers to use alternate GOPATHs for this
case (a unique GOPATH for each project, but also a unique GOPATH for
each testing scenario), or generating a GOPATH based on some other
context. Either way, it isn't appropriate to put the full paths to these
scenarios in the lock file, because the location will be specific to a
machine and/or user. So this has to be done relative to a user-specific
What if the dependency tool supports a special "deps" folder? In the
"lock" file, in addition to specifying the network location from which
the project is fetched, it also (optionally) contains a path, relative
to this "deps" folder, pointed to by an environment variable
(GO_DEP_PATH?), where specific versions of a dependencies can be found.
Fetching a dependency would store it in the GO_DEP_PATH, but under a
path that is specific to a version, so that different versions can exist
simultaneously on my machine. And then, enhance the go tooling to look
at the lock file, and add those relative locations within the
GO_DEP_PATH to the GOPATH for a build? (Probably, adding a tooling
option to generate the effective GOPATH, so all the tooling need not
recreate this logic?)
Now, if the tooling detects a GO_DEP_PATH, instead of vendoring the
dependencies into the project, it saves them into the GO_DEP_PATH, and
saves the path relative to GO_DEP_PATH in the lock file.
I can see potential challenges & limitations to this approach, but
perhaps this is somewhere to start?