The proposed rules around semver and minimal version selection address
> every pain point I've had so far, by aligning available authority with the
> responsibility of the library authors: tell me what versions definitely
> will *not* work, and I'll take it from there.
>
>
Maybe I miss somethi
Not ideal, but you *could* release a new major version where the "breaking"
change is the import path change. Eg if you are on v3 now, make a v4 folder
and the upgrade to v4 process would involve updating import paths. I
wouldn't do this right away since vgo is just a prototype and could change
to
Right, any self import needs to change for the vgo case. (but not for
the go case unless you force everybody currently using your library to
start using semantic versioning paths)
-Nic
On Fri, Feb 23, 2018 at 10:06 AM, Zellyn Hunter wrote:
> On Fri, Feb 23, 2018 at 10:01 AM Nic Pottier wrote:
>
On Fri, Feb 23, 2018 at 10:01 AM Nic Pottier wrote:
> Right, that works for clients of the library (and I did manage to get
> my projects working with that and it now feels magical) but authors of
> modules above v1 are posed with a bit of a quandary as to how to give
> their users a nice vgo ver
On 23 February 2018 at 15:00, Nic Pottier wrote:
> On Fri, Feb 23, 2018 at 7:59 AM, roger peppe wrote:
>> As Russ pointed out to me, you can work around that by using a
>> 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
>> section. If you've got that, it ignores the version t
On Fri, Feb 23, 2018 at 7:59 AM, roger peppe wrote:
> As Russ pointed out to me, you can work around that by using a
> 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
> section. If you've got that, it ignores the version tags.
Right, that works for clients of the library (and
Fantastic post. One small answer below:
On Friday, February 23, 2018 at 2:22:32 AM UTC-5, David Anderson wrote:
>
> The version to use in that replacement was hard to come by. Since vgo was
> unable to compute the right dependency list without this replacement, it
> bailed without giving me any
On 23 February 2018 at 12:31, Nic Pottier wrote:
> Thanks for the great write up Dave, you've inspired me to "try harder" to
> use it on a few of my projects after running into similar issues.
>
> As you noted, my remaining big question mark is how existing libraries that
> are above v1 transition
Thanks for the great write up Dave, you've inspired me to "try harder" to
use it on a few of my projects after running into similar issues.
As you noted, my remaining big question mark is how existing libraries that
are above v1 transition to a vgo style while remaining backwards compatible
du
On Fri, Feb 23, 2018 at 8:20 AM, David Anderson wrote:
> The date+hash format is irritating to construct by hand, but could be
> trivially lifted into a tool (perhaps even vgo itself).
>
Very true. I suffered from the same issue while trying vgo. This could be
improved to ease the adoption of vg
A sidenote is that there seems to always be issues with using kubernetes
client.
Is it structured very un Go-ish?
Very nice writeup!
NB: I was also hit by the casing issue with the same viper dependency.
fre 23 feb. 2018 kl 08:28 skrev David Anderson :
> I should add: even though I spent severa
I should add: even though I spent several hours working through these
issues, I feel very happy about the process and outcome. I have high
confidence that I understand what vgo is doing with my module spec, and
that I know how to tweak its thinking in future. I would contrast this with
my experienc
This is an experience report onboarding vgo for a relatively complex
project (multiple binaries, vast import tree, tricky unidiomatic imports).
I leave it here in the hopes that it guides other people, and potentially
illustrates places where vgo falls short of great. TL;DR it went pretty
well, mod
On Tue, Feb 20, 2018 at 5:14 PM, Dave MacFarlane wrote:
> I really like this, except for the claim that it the blog post that it
> will eliminate vendoring and deprecate GOPATH and the problems that
> will cause for backwards compatibility for things that are currently
> using them. If this is go
On Tue, Feb 20, 2018 at 4:07 PM, David Anderson wrote:
> On Tue, Feb 20, 2018 at 11:37 AM, Russ Cox wrote:
>
>> On Tue, Feb 20, 2018 at 1:55 PM, David Anderson wrote:
>>
>>> I love this. I want it now.
>>>
>>
>> go get -u golang.org/x/vgo :-)
>>
>> I've struggled with `glide` and `dep` dependen
Is there a story for a module that changes domains, like when google
code shutdown or moving to a custom domain for vanity import paths?
Having directives to say "find earlier versions here" or "find later
versions" here seems like it would help downgrades/upgrades. If one of
those old domains sto
On Thu, Feb 22, 2018 at 4:21 AM David Anderson wrote:
> Currently, per the vgo tour, the entire transitive closure gets updated,
> which, per the article's definition, results in a low-fidelity build... If
> you assume that the intent of `vgo get -u` was "the libraries I'm calling
> have new feat
On Wed, Feb 21, 2018 at 3:55 PM, Axel Wagner
wrote:
> On Wed, Feb 21, 2018 at 11:55 PM David Anderson wrote:
>
>> Reading the latest post, https://research.swtch.com/vgo-mvs , a
>> question...
>>
>> It feels to me like there's a missing 5th operation, in additions to the
>> one you proposed: "up
On Wed, Feb 21, 2018 at 11:55 PM David Anderson wrote:
> Reading the latest post, https://research.swtch.com/vgo-mvs , a
> question...
>
> It feels to me like there's a missing 5th operation, in additions to the
> one you proposed: "upgrade all my *direct* dependencies to their latest
> version,
Replying to this thread to drop golang-dev. Please try to keep the two
threads separate. I should not have used the same subject for each. Sorry.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving em
Reading the latest post, https://research.swtch.com/vgo-mvs , a question...
It feels to me like there's a missing 5th operation, in additions to the
one you proposed: "upgrade all my *direct* dependencies to their latest
version, but keep using minimal versions below that." I don't believe there
i
Why would that be a mistake? Working with tags and branches is what the VCS
is for. Extracting a given version and using that per the convention that
the import ends with the major version sounds very reasonable.
On Wed, Feb 21, 2018, 22:51 Zellyn wrote:
> On Wednesday, February 21, 2018 at 4:45
On Wednesday, February 21, 2018 at 4:45:25 PM UTC-5, Bakul Shah wrote:
>
> Something like
> import "foo" v2
> would be mildly preferable to me as
> import "foo/v2"
> can also refer to version 1 of a package named v2 (as opposed
> to version 2 of foo) and the current naming rule
On Wed, 21 Feb 2018 22:24:38 +0100 Sebastien Binet wrote:
>
> On Feb 21, 2018 10:11 PM, "Bakul Shah" wrote:
> >
> > As v2 is only created due to some incompatible change, in my
> > view it is better to have v2 visible in the path. Otherwise
> > it is easy for a reader to get confused when foo.
On Wed, Feb 21, 2018 at 10:17 PM Peter Bourgon wrote:
> ·Any· change to the exported API of a package except adding new
> top-level identifiers can be considered an incompatible (breaking)
> change.
>
> https://blog.merovius.de/2015/07/29/backwards-compatibility-in-go.html
I should probably go
On Feb 21, 2018 10:11 PM, "Bakul Shah" wrote:
On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson
wrote:
>
> That's not necessarily true.
> The tool can understand from the tag and assert or even rewrite the
imports
> to make the compiler happy.
>
> On Wed, Feb 21, 2018, 21:51 Sam Whited wrote:
On Wed, Feb 21, 2018 at 1:10 PM, Bakul Shah wrote:
> On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson
> wrote:
>>
>> That's not necessarily true.
>> The tool can understand from the tag and assert or even rewrite the imports
>> to make the compiler happy.
>>
>> On Wed, Feb 21, 2018, 21:51 Sam
On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson
wrote:
>
> That's not necessarily true.
> The tool can understand from the tag and assert or even rewrite the imports
> to make the compiler happy.
>
> On Wed, Feb 21, 2018, 21:51 Sam Whited wrote:
>
> > On Wed, Feb 21, 2018, at 14:46, Henri
On Wed, Feb 21, 2018, at 14:57, Russ Cox wrote:
> My plan is that this is in one of tomorrows' post. Sorry for seeming like
> I'm withholding information. I'm posting as they are finished. :-)
Sounds good, I look forward to reading it and continuing to digest the
proposal. I've had a hard time co
For people who haven't seen it yet: research.swtch.com/vgo-import is the
post Sam's referring to.
On Wed, Feb 21, 2018 at 2:22 PM, Sam Whited wrote:
> Something that is still unclear to me even after reading todays post is
> how I would manage the various package import paths created by the impo
That's not necessarily true.
The tool can understand from the tag and assert or even rewrite the imports
to make the compiler happy.
On Wed, Feb 21, 2018, 21:51 Sam Whited wrote:
> On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote:
> > But wait. Wasn't there a mention of archive downloads i
But wait. Wasn't there a mention of archive downloads instead of relying on
the different VCS's?
In the GitHub case I guess it amount to downloading releases (or any commit
I guess) as a zip or tarball.
On Wed, Feb 21, 2018, 20:54 Sam Whited wrote:
> On Wed, Feb 21, 2018, at 13:49, Peter Bourgo
On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote:
> But wait. Wasn't there a mention of archive downloads instead of relying on
> the different VCS's?
>
> In the GitHub case I guess it amount to downloading releases (or any commit
> I guess) as a zip or tarball.
My understanding was that th
Something that is still unclear to me even after reading todays post is how I
would manage the various package import paths created by the import
compatibility rule.
The way this is currently done is through tools such as gopkg.in, will the
import path be modified and rewritten by a package serv
On Wed, Feb 21, 2018 at 11:22 AM, Sam Whited wrote:
> Something that is still unclear to me even after reading todays post is how I
> would manage the various package import paths created by the import
> compatibility rule.
> The way this is currently done is through tools such as gopkg.in, will
On Wednesday, February 21, 2018 at 2:23:07 PM UTC-5, Sam Whited wrote:
>
> Something that is still unclear to me even after reading todays post is
> how I would manage the various package import paths created by the import
> compatibility rule.
> The way this is currently done is through tools s
On Wed, Feb 21, 2018, at 13:49, Peter Bourgon wrote:
> > If not, do I maintain separate /v2 and /v3 trees in my directory and
> > copy/paste changes between them when I want to release security fixes as a
> > point release?
>
> Yes, this is what vgo expects.
This (and the other alternatives) s
Unfortunately, the rules also create some new perverse incentives, with
some, IMO, nastier failure modes and remediations. That's one of the things
i'll be elaborating on in my doc (hopefully) next week.
That said, one of the points Russ and i agree on is that dep does allow
more expressiveness
Actually it seems viper imports it with lower case.
I don't remember if import paths are to be considered different if they
only differ in case.
ons 21 feb. 2018 kl 09:04 skrev Henrik Johansson :
> I am currently running `vgo build` on a decent sized project that has a
> few dependencies.
>
> It
I am currently running `vgo build` on a decent sized project that has a few
dependencies.
It bailed on import case it seems:
import "github.com/spf13/jwalterweatherman": module path of repo is
github.com/spf13/jWalterWeatherman, not github.com/spf13/jwalterweatherman
(wrong case)
This is a trans
Two more use cases of vendor that I would like to keep:
- A single audit trail for all go code going into production binaries in a
git log.
- A single place to enforce upgrades for multiple binaries in a monorepo.
Perhaps a top-level meta-module could do the trick?
On Tuesday, February 20, 2018
One shortcoming I see in this proposal compared to dep is the necessity of
operating a proxy to achieve reasonable security. Without a proxy or a lock
file, a repository take-over as it happened in the case of go-bindata will
lead to vgo automatically downloading potentially malicious code.
In the
Hi,
I'd like your input on two concern I have, one as a tool developer and
one with regard to reproducible builds.
With go and go get, it is expected that code will not compile until
all dependencies have been explicitly downloaded. Hence, it is
acceptable for tools such as staticcheck to also fa
On Tue, 20 Feb 2018 12:20:19 -0500
Russ Cox wrote:
> https://research.swtch.com/vgo.
> Russ
Amazing! The 'minimal version selection' approach is briliant.
Where it lacks for me is about keeping up with security patches.
If my module keeps libFoo at 1.2.3 it will not see a backported fix
that c
On Tue, Feb 20, 2018 at 2:29 PM, Bakul Shah wrote:
> On Tue, 20 Feb 2018 13:02:47 -0800 David Anderson
> wrote:
> >
> > As a counterpoint to this: with vgo, I plan to make all my binary modules
> > specify that they want the latest versions of everything,
>
.
>
> The right choice here is no
On Tue, 20 Feb 2018 13:02:47 -0800 David Anderson wrote:
>
> As a counterpoint to this: with vgo, I plan to make all my binary modules
> specify that they want the latest versions of everything, and update that
> pinning every couple of weeks/months. If I encounter bugs, I'll report
> them, and m
I really like this, except for the claim that it the blog post that it
will eliminate vendoring and deprecate GOPATH and the problems that
will cause for backwards compatibility for things that are currently
using them. If this is going to result in removing language features
(ie. vendoring), shoul
I think we're agreeing, with different words (but please correct me if I'm
wrong!).
Yes, active maintenance is required with vgo, as demonstrated in the tour.
But crucially, I do not get held back by library writers that don't update,
I'm only held back by my own laziness in failing to update at t
2018-02-20 13:02 GMT-08:00 David Anderson :
> [snip]
>
> I also believe the tooling around vgo should encourage/make default this
> behavior for binary modules (and maybe for library modules as well, though
> that's less clear to me). The default behavior when writing Go programs
> should be to use
On Tue, 20 Feb 2018 15:51:39 -0500 Russ Cox wrote:
>
> On Tue, Feb 20, 2018 at 3:46 PM, Bakul Shah wrote:
>
> > May be one can write a tool around or similar to "vgo test" to
> > test and update not to the latest but some earlier version.
> > For example, if pkg A currently imports C v1.x and B
On Tue, Feb 20, 2018 at 11:37 AM, Russ Cox wrote:
> On Tue, Feb 20, 2018 at 1:55 PM, David Anderson wrote:
>
>> I love this. I want it now.
>>
>
> go get -u golang.org/x/vgo :-)
>
> I've struggled with `glide` and `dep` dependency hell a lot in my Go
>> projects (especially those that use the Ku
On Tue, Feb 20, 2018 at 12:46 PM, Bakul Shah wrote:
> On Tue, 20 Feb 2018 11:55:00 -0800 "Devon H. O'Dell" <
> devon.od...@gmail.com> wrote:
> Devon H. O'Dell writes:
> > 2018-02-20 11:39 GMT-08:00 Russ Cox :
> > > On Tue, Feb 20, 2018 at 2:35 PM, Devon H. O'Dell <
> devon.od...@gmail.com>
> > >
On Tue, Feb 20, 2018 at 3:46 PM, Bakul Shah wrote:
> May be one can write a tool around or similar to "vgo test" to
> test and update not to the latest but some earlier version.
> For example, if pkg A currently imports C v1.x and B imports C
> v1.y, through iterative testing one may find C v1.z
On Tue, 20 Feb 2018 11:55:00 -0800 "Devon H. O'Dell"
wrote:
Devon H. O'Dell writes:
> 2018-02-20 11:39 GMT-08:00 Russ Cox :
> > On Tue, Feb 20, 2018 at 2:35 PM, Devon H. O'Dell
> > wrote:
> >>
> >> With regards to minimum version selection, if I depend on some feature
> >> present, this comes wi
2018-02-20 11:39 GMT-08:00 Russ Cox :
> On Tue, Feb 20, 2018 at 2:35 PM, Devon H. O'Dell
> wrote:
>>
>> With regards to minimum version selection, if I depend on some feature
>> present, this comes with two implicit dependencies: correctness and
>> safety. My knee-jerk reaction here is that the ti
On Tue, Feb 20, 2018 at 2:35 PM, Devon H. O'Dell
wrote:
> With regards to minimum version selection, if I depend on some feature
> present, this comes with two implicit dependencies: correctness and
> safety. My knee-jerk reaction here is that the time folks spend
> "telling the package manager,
On Tue, Feb 20, 2018 at 1:55 PM, David Anderson wrote:
> I love this. I want it now.
>
go get -u golang.org/x/vgo :-)
I've struggled with `glide` and `dep` dependency hell a lot in my Go
> projects (especially those that use the Kubernetes client library, which
> abuses "I, the library author,
With regards to minimum version selection, if I depend on some feature
present, this comes with two implicit dependencies: correctness and
safety. My knee-jerk reaction here is that the time folks spend
"telling the package manager, 'no, use at least Y,'" will largely be
in response to these sorts
I love this. I want it now.
I've struggled with `glide` and `dep` dependency hell a lot in my Go
projects (especially those that use the Kubernetes client library, which
abuses "I, the library author, can define byzantine constraints on my
users" to the extreme). The way I've described it informal
59 matches
Mail list logo