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

Hi Göcs, Could you expand on your question, including a bit more about the scenario you are in, what you are seeing currently, and what you would like to see instead? It would probably help to include a simplified example that is representative of your question or issue. For example (and

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

Is it possible to restrain of having 2 files in my workspace/project while keeping 2 versions of the same repo? On Wednesday, February 21, 2018 at 1:20:54 AM UTC+8, Russ Cox wrote: > > Hi everyone, > > I have a new blog post you might be interested in. > https://research.swtch.com/vgo. > > I'll

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

I read through quite a bit of those docs, but somehow missed that - thanks Daniel. On Tuesday, February 27, 2018 at 4:35:32 PM UTC-7, Daniel Theophanes wrote: > > Hi Robert, you still can do that. Just add a "replace" directive in the > local go.mod. > > Please see

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

Hi Robert, you still can do that. Just add a "replace" directive in the local go.mod. Please see https://research.swtch.com/vgo-tour for more details. On Tuesday, February 27, 2018 at 1:47:40 PM UTC-8, Robert Carlsen wrote: > > Before with the naive GOPATH workflow and also with vendoring, it

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

Before with the naive GOPATH workflow and also with vendoring, it was super easy for me to debug problems with and contribute to upstream packages. With vgo, I can't just cd into vendor/github.com/foo/bar to test out fixes for bugs, etc. Without vendoring I could just cd into

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

And I later found https://godoc.org/golang.org/x/vgo/vendor/cmd/go, which looks like where you'll be developing new material from the old docs. --dave On Sunday, February 25, 2018 at 11:00:54 AM UTC-5, David Collier-Brown wrote: > > I'm following the discussion and using the blog descriptions,

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

I'm following the discussion and using the blog descriptions, but where are the "man pages"? A search at golang.org for vgo only points me to /src/crypto/x509/root_darwin_armx.go (:-)) Seriously, though, I'll happily help develop and/or edit reference material: I was an O'Reilly author in a

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

On 24/02/18 04:05 PM, Maxim Ivanov wrote: I am replying mostly to https://resea rch.swtch.com/vgo-import article. ... IMHO right solution vgo should promote is to apply semver trick described here: https://github.com/dtolnay/semver-trick/blob/master/README.md . In a nutshell it suggests that

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

On Sunday, February 25, 2018 at 1:08:31 AM UTC-5, Sam Whited wrote: > > FYI, there is an active CL for this here: https://golang.org/cl/95578 > Thanks Sam -- I found it, and it's working fine. I'm still curious as to what I'm doing wrong in executing the tests in x/vgo . --- SER -- You

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

Hi! On Fri, Feb 23, 2018 at 06:23:33PM -0800, Spencer Nelson wrote: > Is it possible for me to have different minor/patch versions for different > modules in one repository? For example, suppose I have this: > > github.com/my/thing/go.mod > github.com/my/thing/blue/go.mod > > And

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

On Sat, Feb 24, 2018, at 21:44, Sean Russell wrote: > I'm working on adding support for Bitbucket, per your comment in #23950 > . I'm struggling a bit with > executing the tests in x/vgo -- should I expect vgo test to work? I feel > like I'm missing

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

I am replying mostly to https://resea rch.swtch.com/vgo-import article. It is proposed that "moauth" author should do double work, even if his code works absolutely fine with either verion of oauth. This viral effect will be causing chain reaction and a lot of people will be creating

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

I'd like to better understand how multiple-module repositories work if tagged commits are used for minor and patch versioning. My understanding is that major version increments are controlled with import paths, while minor and patch version increments are controlled with commit tags. Is it

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

Russ, I'm working on adding support for Bitbucket, per your comment in #23950 . I'm struggling a bit with executing the tests in x/vgo -- should I expect vgo test to work? I feel like I'm missing something obvious. I added unit tests first and

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

Hi Russ, I had a question about this: > We expect that most developers will prefer to follow the usual “major branch” convention, in which different major versions live in different branches. In this case, the root directory in a v2 branch would have a go.mod indicating v2, like this: It

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

> > Some forms of attempted versioning don't do well with vgo (:-)) > I tried a main named "consumer" that imported "gopkg.in/Shopify/sarama.v1", > and got > ``` > [davecb@miles consumer]$ vgo build > can't load package: import cycle not allowed > package gopkg.in/Shopify/sarama.v1 > imports

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

> Ah… yes, that would probably let me work on it. Didn’t occur to me > — thanks for pointing it out. It seems unpleasant to deal with, > though, especially since there is a non-zero chance that you then > commit your go.mod file with that change inadvertently. See my proposal here:

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

Ah… yes, that would probably let me work on it. Didn’t occur to me — thanks for pointing it out. It seems unpleasant to deal with, though, especially since there is a non-zero chance that you then commit your go.mod file with that change inadvertently. I think a local replace will do that.

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

On Fri, Feb 23, 2018 at 3:34 PM, Richard Wilkes wrote: > Overall, I really like the direction vgo is headed. > > One thing that seems to be difficult, if not impossible to do (I've yet to > figure out how to do so, anyway) is to work with code that has yet to be >

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

Overall, I really like the direction vgo is headed. One thing that seems to be difficult, if not impossible to do (I've yet to figure out how to do so, anyway) is to work with code that has yet to be committed and resides outside of your module. This is a frequent occurrence for me, as I often

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

On Thu, Feb 22, 2018 at 9:50 AM dc0d wrote: > And the first idea is about having packages that does not harm the > environment (like by importing reflect or executing external commands), and > seems to be a feasible goal. > Apologies, I was ambiguous in my quote, I

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

Thanks Axel, You are right about env-vars and as I've noted, there might be security concerns. The main goal here was to represent an idea for the source of the import. It can be the module descriptor of vgo. And the first idea is about having packages that does not harm the environment (like

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

On Thu, Feb 22, 2018 at 7:10 AM dc0d wrote: > I'm looking forward to see this in official releases too! > > Also I would like to: > > - Have a mechanism for safe dependency packages (as in Safe-Tcl > - this implies it would

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

And also I would like the $GOPATH to stay. I clean it up from time to time - also $GOPATH/bin which go install uses. On Thursday, February 22, 2018 at 9:40:17 AM UTC+3:30, dc0d wrote: > > I'm looking forward to see this in official releases too! > > Also I would like to: > > - Have a mechanism

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

I'm looking forward to see this in official releases too! Also I would like to: - Have a mechanism for safe dependency packages (as in Safe-Tcl - this implies it would be possible to have meta-data other than versions for packages, too). - This one

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

> > Since the `vendor` folder is gone, is vgo able to manage and use a kind of > `mirror` folder, which would contain the .zip archives of the project > dependencies? This folder could be committed with the project source code. I have the same question. Can we vendor modules? Code consumers

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

I like this! One question: Some of us commit their `vendor` folder, to be able to build the project without any network access after the initial checkout ("offline mode"). Since the `vendor` folder is gone, is vgo able to manage and use a kind of `mirror` folder, which would contain the .zip

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

As far as I understand it - github.com/user/foo is expected to house package foo for SemVer 0.x.x – 1.x.x - github.com/user/foo/v2 is expected to house package foo for SemVer 2.x.x - github.com/user/foo/v3 is expected to house package foo for SemVer 3.x.x And so on. Appending the additional path

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

I'm wondering how to respond to security patches. After a patch, any go.mod file mentioning an older version of the library is a candidate for version-bumping: download the new version, test, and do a commit with the new version number if all goes well. It's nice that it can be done in any

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

Would you be willing to create an example illustrating how a versioned package should look with major version changes? You have great examples for the minor/patch changes, but I don't see any concrete examples for a major version bump. On Tuesday, February 20, 2018 at 12:20:54 PM UTC-5, Russ

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

I'd like to understand the expectations of library maintainers better. I am particularly thinking about the reference to setting major versions through import paths, like github.com/go-yaml/yaml/v2. Is the expectation that library owners would need to change the structure of their project like

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

On Tue, Feb 20, 2018 at 1:17 PM, Zellyn wrote: > A couple of initial questions: > >- The "pretend you're importing github.com/foo/bar but actually pull >it from localgit.host/foo/bar" functionality of dep was going to really >simplify things for us. I can't quite

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

A couple of initial questions: - The "pretend you're importing github.com/foo/bar but actually pull it from localgit.host/foo/bar" functionality of dep was going to really simplify things for us. I can't quite tell whether vgo includes that functionality or not. We would want to do