Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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 >

Re: [go-nuts] Go += Package Versioning

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.

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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 >

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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,

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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,

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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: >

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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,

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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)

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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 >

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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,

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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),

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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,

Re: [go-nuts] Go += Package Versioning

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 >>

Re: [go-nuts] Go += Package Versioning

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.

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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.

Re: [go-nuts] Go += Package Versioning

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 >

Re: [go-nuts] Go += Package Versioning

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,

Re: [go-nuts] Go += Package Versioning

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

Re: [go-nuts] Go += Package Versioning

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