This sort of issue around the vendor experiment is one I've been concerned
with for some time. I'm glad it's finally being discussed. I have a fairly
On Tuesday, November 3, 2015 at 4:39:37 PM UTC-8, minux wrote:
Only applications should vendor packages.
^ This. And I believe a way to do this is to only have the vendor/ pull
from a location relative to the "main" package of an application (rather
than relative to the current package). This will prevent impossible diamond
dependencies (package a vendors package c, package b vendors packages c,
c.type returned by a.func is incompatible with c.type accepted by b.func),
I illustrate this issue in a simple application here:https://github.com/conslo/vendor_problem.
However by leaving the dynamic
nature of the vendor folder location, one can still share a vendor folder
among multiple projects (github.com/vendor as a silly example for anything
I don't personally agree with rewriting import paths, and I think the
community has shown it doesn't either (hence this experiment). And as for
letting external tooling solve these problems, I feel that goes against the
idea that anything should be "go get-able", requiring tooling outside
what's provided by the language to interact with projects seems... silly.
Other languages solve these problems by having package managers: a
canonical source with canonical names, and version numbers for packages.
Neither of these are being provided or enforced, and expecting a tool to do
some sort of versioning resolution without any sort of in-built version
identification (semver, anyone?) seems... also silly.
In addition, the general theme I've seen, including with this vendor
experiment, seems to assume "a future version of package x will always be
compatible with a previous version of package x". When you work in a
totally vendored environment where there's only one version of any package
at any time (sound familiar?) this works fine; breaking changes are made
atomically, everyone is compatible with each other, and bad versions are
fixed and never seen again. However, this is not what open source is like;
when a package needs to make breaking changes, it has to maintain the old
version for a while so people have time to transition, people try to pin to
versions, but we're not all pinned to the same one. There are multiple
versions (some/many incompatible with each other) of any one dependency in
use. This is why communities have, mostly, learned to use semantic
versioning: I need a feature in 1.5, and you need 1.6, so above 1.6 and
below 2.0 should work for both of us, if we find a version that doesn't
work there should be a patch version after it that fixes the break. As of
right now there is not widely accepted mechanism for declaring versions of
dependencies, just a canonical URL and an expectation that that URL will
never have changes that break me, there's gopkg.in (which is awesome!), but
if a package has internal packages it doesn't work unless the developer
specifically includes it (because, you know, no relative imports ;)). Some
things enable pinning, but they generally pin to a commit hash, not a
"version", so any dependency resolution isn't really enabled. Perhaps a
discussion of versioning as a whole is in order? An endorsed mechanism for
declaring versions (tags/branches? I know git/mercurial but not bazaar or
others), and/or an endorsed method of declaring versions of dependencies
would be incredible (for the later, I actually think a language addition
for suffixing the version in the import would be awesome: import name
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.