Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: support easy way to install a remote binary while respecting remote 'replace' and 'exclude' directives #31173
What version of Go are you using (
I'm still not convinced that long-term use of
(Note that we do support it, in the sense that it remains possible to check out the repository and run
In particular, the compatibility argument for using
So I would like some more detail: @rogpeppe, why does
OK, here's some detail on the replacements used by Juju currently. I speak at some remove, because I haven't been directly involved in the Juju code base for a little while now, but I have been historically familiar with some of the issues.
It might be possible to move away from replace statements in the long term, but it's not necessarily possible in practice without hard-forking multiple external repositories, which has its own on-going cost. It's certainly not going to happen in the short to medium term, which means that replace statements are going to be a necessity for building juju for a while to come.
And even the need for these particular replace statements is dropped eventually, another similar issue might well arise in the meantime. The open source world is not always clean. Some kind of replace statement is a crucial band-aid at times, and one which anyone installing the juju commands, not just developers, will need to apply.
github.com/altoros/gosigma => github.com/juju/gosigma
Fixes races in tests and code. https://github.com/Altoros/gosigma/pull/1/files.
There's been a PR open since 2017-05-23 without response.
Making a hard fork of this probably wouldn't be that hard to do, although might
gopkg.in/yaml.v2 => github.com/juju/yaml
A tweak to the accepted floating point syntax. No new API. A small but
holds a floating point number or a string. Changing this behaviour might
Changing this unilaterally inside juju could break other code. For
Changing this across the entire code base would be hard, as many external
gopkg.in/mgo.v2 => github.com/juju/mgo
19 commits. Some new API.
The parent repository is no longer maintained, and was not generally
Changing this dependency to use github.com/juju/mgo throughout
Hi @bcmills, briefly cherry picking a couple points you made:
...unless of course part of the way you selected the module versions as the binary author is via a
That is not my concern -- modules provide 100% reproducible builds, etc.
The compatibility argument is not about future breaking changes causing problems for consumers, and is more about incompatibilities that exist when a binary is being published given for example (a) semver is not always perfectly followed in practice and (b) people use v0 dependencies from the "compatibility free zone". Either of those mean MVS by itself can select problematic versions of
That's a bit of a circular argument, though.
The central question here, as I see it, is: should
@rogpeppe, thanks for the detail.
It seems to me that since
Specifically in relation to
Could you give some more detail about why changing the import path would require a major version change? (Do packages pass through
The issue with
That is, I suspect you'll want to maintain a fork of the package for compatibility with existing YAML files, but you'll want to use that fork only for the parts of the code that consume existing files.
On the other hand, if you replacement really is benign for your dependencies, then perhaps the
Yes. For example see this package. The forked mgo package can't type-alias the original
I agree that replacements are not desirable and can usually be worked around in time (with negotiation with upstream maintainers, hard forks etc), but the fact remains that they are important at the time for making working products.
Even if the replacement is just a "temporary" fix, it can be an important one, and I consider it important that it's possible to publish a predictably-versioned Go binary with the fix in place until the replacement can be removed. Telling the user to do their own git clone (working out the correct incantation for that is non-obvious with vanity import paths) or similar is not a good solution.
I think Russ's words, aptly quoted above, bear repeating once again:
Please, let's provide that flexibility for all users of Go modules.
BTW I would be perfectly happy if file-path replacements yielded an error in this case. I do consider file-path replacements suitable for developers only (and they're not a fundamental part of VCS, which replacements and exclusions in general are).
This has an interesting interaction with #33848.
#33848 proposes to use the main module's
Also like a
Perhaps #26904 provides a better way forward: one option we're considering there (from among many alternatives) is adding some new keyword to the
Those paths are necessarily always import paths, not filesystem paths, which obviates the concern about treating filesystem paths and module paths differently.
Unfortunately, applying only a subset of the main module's directives still poses a testing problem: it would still mean that the module could be built — and would need to be tested in — a third configuration that is neither the same as the view from inside that module, nor from an external module.
The more I think about it, though, the more convinced I am that an “install from semi-inside” command should not be
You might even imagine that a build in this mode should not resolve missing imports: if the point is to exactly reproduce what the developer would have built, then the developer necessarily needs to record all of the versions that they intended to use.
This seems like a good idea to me.