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

[thepudds1460]

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 making something 
up):

  "I have module 'foo' located in a remote git server, and the latest 
commit is tagged v1.2.3. I just did a fresh git clone to 
/tmp/scratchpad/foo, and now I want to do ... but instead I am seeing ..."

Also, it might be good to start a new thread with a new subject, which will 
make it easier for people to find your question. (This thread has many 
people on it, and was primarily about reaction to the initial versioned 
modules blog series from back in February).

Best,
--thepudds

On Tuesday, November 27, 2018 at 9:22:17 AM UTC-5, Göcs Jëss wrote:
>
> 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 try to watch this thread to answer any questions.
>>
>> Best,
>> Russ
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Göcs Jëss]

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 try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Carlsen]

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 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 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 
>> $GOPATH/src/github.com/foo/bar, test a patch - commit, push - and submit 
>> a PR to the 3rd party project.  With vgo, I now have to fork+clone that 
>> repository, modify my go.mod file to point to my fork, patch my clone, 
>> commit and push to my fork before I can rebuild and test the patch.  Yuck.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Theophanes]

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 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 
> $GOPATH/src/github.com/foo/bar, test a patch - commit, push - and submit 
> a PR to the 3rd party project.  With vgo, I now have to fork+clone that 
> repository, modify my go.mod file to point to my fork, patch my clone, 
> commit and push to my fork before I can rebuild and test the patch.  Yuck.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Carlsen]

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 
$GOPATH/src/github.com/foo/bar, test a patch - commit, push - and submit a 
PR to the 3rd party project.  With vgo, I now have to fork+clone that 
repository, modify my go.mod file to point to my fork, patch my clone, 
commit and push to my fork before I can rebuild and test the patch.  Yuck.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Collier-Brown]

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, 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 previous life.
>
> --dave
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Collier-Brown]

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 previous life.

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Collier-Brown]

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 "oauth/v1" imports "oauth/v2" and type 
aliases all common types visible in API. Then "moauth" doesn't need a 
new semver release at all, it stops being viral and whole dependency 
chain becomes much much simpler.
This is one of the two approaches that the Multics folks used when they 
ran into the version-skew problem in a heavily versioned collection of 
shared libraries.


They wrote "updaters" and "downdaters", that respectively took an old 
call and called the new code, or took a new call and mapped it into old 
code.


Also used in Solaris and inside Linux glibc, so we've independently 
re-invented it at least four times (;-))


Go community is going to to do pretty much whatever Russ tells them 
with imminent vgo release, if smever trick indeed solves this viral 
problem, it should be encouraged from day 0.


I think the mechanics of doing multiple versions deserves a blog 
article, as it's been touched on in the group a couple of times.


--dave
[I also think Russ was just using Mo writing extra libraries as an 
illustration]
[see also "Dependency hell is NP-complete" at 
https://research.swtch.com/version-sat and
“DLL Hell”, and avoiding an NP-complete problem, at 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/ 
]


--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sean Russell]

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 received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alex Efros]

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 suppose my current commit is tagged with v1.0.0.
> 
> Now I fix a bug in github.com/my/thing/blue. How do I indicate that 
> github.com/my/thing/blue is at v1.0.1 without changing 
> github.com/my/thing's version?

Russ already answered this in one of articles - use tag "blue/v1.0.1".

-- 
WBR, Alex.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sam Whited]

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 something obvious.

FYI, there is an active CL for this here: https://golang.org/cl/95578

—Sam

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Maxim Ivanov]

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 unnecessary 
major semver releases. "moauth" author doesn't need to do anything, but 
once vgo is out , he'll be receiving requests from "aws" to do theese 
releases and "aws" itself will be blocked on somebody else without a way to 
move forward with "oauth/v2".

It will also cause combinatorial explosion, just imagine if "moauth" 
depends on "oauth" and "samlauth", would it need to release 4 major semver 
versions for all combinations of dependencies visible in API? Looks like it 
is inevitable, as users of "moauth" can decide to use types from either 
version of "oauth" and "samlauth".

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 "oauth/v1" imports "oauth/v2" and type aliases 
all common types visible in API. Then "moauth" doesn't need a new semver 
release at all, it stops being viral and whole dependency chain becomes 
much much simpler.

Go community is going to to do pretty much whatever Russ tells them with 
imminent vgo release, if smever trick indeed solves this viral problem, it 
should be encouraged from day 0.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Spencer Nelson]

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 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 suppose my current commit is tagged with v1.0.0.

Now I fix a bug in github.com/my/thing/blue. How do I indicate that 
github.com/my/thing/blue is at v1.0.1 without changing 
github.com/my/thing's version?

On Tuesday, February 20, 2018 at 9: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 try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sean Russell]

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 they're failing (as expected) but not for the 
reasons I'd expect:

➜  vgo git:(master) ✗ vgo test ./vendor/cmd/go/internal/modfetch/   
   
vgo: import "github.com/serussell/vgo/vendor/cmd/go/internal/modfetch" ->
import "cmd/go/internal/modconv" [/usr/local/go/src/cmd/go/internal/
modconv]: open /usr/local/go/src/cmd/go/internal/modconv: no such file or 
directory

Many similar messages follow this. Why is it looking in GOROOT?  The 
project directory structure still follows the legacy 
$GOPATH/src/github/serussell/vgo pattern.

I'm hacking on fetch.go, but I'd feel more comfortable if I could execute 
the unit tests.

Thanks,

--- SER

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[bits128]

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 seems like there's subdirectories and this major branch convention that 
are both supported by vgo. In my anecdotal experience no repositories 
follow this convention in Go or other languages (can't actually think of a 
single one other than the ones forced to by gopkg.in which seems relatively 
unused these days). Master branch is whatever latest is and has v2.3.4 tags 
in it's history. Tags exist to separate everything (not just minor 
versions). If it's necessary to patch an old version, a branch is 
temporarily created off the last v1 tag, commits pushed, a new tag pushed, 
and the branch summarily deleted. There is no branch for versions, it's 
just current master/dev/feature branches + version tags.

Having said that, I've tested the above described workflow with vgo (just 
having tags that say v2.0.0, v2.0.1 and no branches) and it does seem to 
work (though as an aside it is pretty confusing/annoying to have to change 
the require statement to say both /v2 as well as v2.0.0 when you upgrade 
the dependency in go.mod, not sure why that's required). So my question is: 
Although this works now, is it intended? As it doesn't seem as thoroughly 
described as the other two workflows in the blog, and I want to ensure that 
working without a v2/v3... branch is not accidental functionality that will 
disappear since as I explained above I've never seen this (or the other) 
described workflow in the post to be massively adopted by anyone 
(especially outside the Go community).

Of course my argument is coming down to preference and anecdotes, so I'd be 
willing to do some repo-scraping to prove this across all languages if 
needed. So far I've really liked the proposal posts and am generally on 
board with the changes, will continue to follow along and play with vgo.

Thanks for all your efforts.

Aaron

On Tuesday, February 20, 2018 at 9: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 try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Collier-Brown]

>
> 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 gopkg.in/Shopify/sarama.v1
> import cycle not allowed
> package gopkg.in/Shopify/sarama.v1
> imports gopkg.in/Shopify/sarama.v1
>
 

> [davecb@miles consumer]$ cat go.mod 
> module "gopkg.in/Shopify/sarama.v1"
>
```

The main.go started with 
```
package main 

import (
samara "gopkg.in/Shopify/sarama.v1"
"os"
"log"
"os/signal"
)

func main() {
consumer, err := samara.NewConsumer([]string{"10.5.70.111:9092"}, nil)
if err != nil {
panic(err)
}
```

I didn't expect it to work, but the nature of the error might be 
interesting 

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Aram Hăvărneanu]

> 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:
https://github.com/golang/go/issues/23972#issuecomment-368077927

-- 
Aram Hăvărneanu

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Wilkes]

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. Something like: replace "
> foo.com/my/pkg" v1.5.2 => ../local-clone-with-changes
>
 

Put that in the top-level module, and it should override that import 
> throughout the build with your local copy, pending changes and all. Or is 
> that not what you were trying to do here?


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Anderson]

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
> committed and resides outside of your module. This is a frequent occurrence
> for me, as I often have to work on groups of changes that interact between
> multiple repos. Yes, I'll eventually check those changes in, but usually
> not while actively working on the problem.
>

I think a local replace will do that. Something like: replace "
foo.com/my/pkg" v1.5.2 => ../local-clone-with-changes

Put that in the top-level module, and it should override that import
throughout the build with your local copy, pending changes and all. Or is
that not what you were trying to do here?


> Related to this, it took a few minutes to realize that you really can't
> "downgrade" to a commit-level entry with the tool when a tag is present in
> the repo -- you have to manually edit it to get the desired behavior. I put
> downgrade in quotes because what I was actually trying to do was to get the
> actual latest (HEAD) code, but could not without manually futzing with the
> go.mod file. This is also something that I frequently need to do -- and I'm
> relatively sure I'm not alone -- so it seems like the tool should make this
> easy, not hard.
>
> Despite the two problems above, an inability to work with GitHub
> Enterprise (filed in a bug report), and concern over how IDEs will work
> with library source, I'm already enjoying working with vgo.
>
> - Rich
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard Wilkes]

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 have to work on groups of changes that interact between 
multiple repos. Yes, I'll eventually check those changes in, but usually 
not while actively working on the problem.

Related to this, it took a few minutes to realize that you really can't 
"downgrade" to a commit-level entry with the tool when a tag is present in 
the repo -- you have to manually edit it to get the desired behavior. I put 
downgrade in quotes because what I was actually trying to do was to get the 
actual latest (HEAD) code, but could not without manually futzing with the 
go.mod file. This is also something that I frequently need to do -- and I'm 
relatively sure I'm not alone -- so it seems like the tool should make this 
easy, not hard.

Despite the two problems above, an inability to work with GitHub Enterprise 
(filed in a bug report), and concern over how IDEs will work with library 
source, I'm already enjoying working with vgo.

- Rich

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Axel Wagner' via golang-nuts]

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 wasn't trying to say anything
about the first point at all.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 by importing reflect or executing external commands), and 
seems to be a feasible goal.

On Thursday, February 22, 2018 at 11:31:35 AM UTC+3:30, Axel Wagner wrote:
>
> 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 be 
>> possible to have meta-data other than versions for packages, too).
>> - This one looks like a minor change in import syntax and might bring in 
>> some security concerns: being able to use env-vars in imports: import 
>> "$MY_OTHER_PKG".
>>
>
> Please don't. This is the antithesis to what vgo is trying to do. vgo 
> tries very hard to marry reproducible builds with simplicity. Having 
> environment variables determine what gets built destroys that completely.
>
> The occasional edge-case that might benefit from this should write their 
> own tool which generates an appropriate package.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Axel Wagner' via golang-nuts]

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 be
> possible to have meta-data other than versions for packages, too).
> - This one looks like a minor change in import syntax and might bring in
> some security concerns: being able to use env-vars in imports: import
> "$MY_OTHER_PKG".
>

Please don't. This is the antithesis to what vgo is trying to do. vgo tries
very hard to marry reproducible builds with simplicity. Having environment
variables determine what gets built destroys that completely.

The occasional edge-case that might benefit from this should write their
own tool which generates an appropriate package.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 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 looks like a minor change in import syntax and might bring in 
> some security concerns: being able to use env-vars in imports: import 
> "$MY_OTHER_PKG".
> - I love managing major versions in git by having different branches for 
> major versions because it makes patching fixes much more logical and 
> cleaner. It would be great to be able to perform go get based on branch 
> name too - the concept is common in major source controls of today.
>
>
> On Tuesday, February 20, 2018 at 8:50:54 PM UTC+3:30, Russ Cox wrote:
>>
>> Hi everyone,
>>
>> I have a new blog post you might be interested in.
>> https://research.swtch.com/vgo.
>>
>> I'll try to watch this thread to answer any questions.
>>
>> Best,
>> Russ
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 looks like a minor change in import syntax and might bring in 
some security concerns: being able to use env-vars in imports: import 
"$MY_OTHER_PKG".
- I love managing major versions in git by having different branches for 
major versions because it makes patching fixes much more logical and 
cleaner. It would be great to be able to perform go get based on branch 
name too - the concept is common in major source controls of today.


On Tuesday, February 20, 2018 at 8:50:54 PM UTC+3:30, Russ Cox wrote:
>
> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[matthewjuran]

>
> 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 may not 
have a way to get to my proxy or contact me and the project may become 
unbuildable due to lost dependencies.

Matt

On Wednesday, February 21, 2018 at 8:34:04 AM UTC-6, Nicolas Grilly wrote:
>
> 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 archives of the project 
> dependencies? This folder could be committed with the project source code.
>
> The yarn package manager, for example, has a similar feature:
> https://yarnpkg.com/blog/2016/11/24/offline-mirror/
>
> On Tuesday, February 20, 2018 at 6:20:54 PM UTC+1, Russ Cox wrote:
>>
>> I have a new blog post you might be interested in.
>> https://research.swtch.com/vgo.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nicolas Grilly]

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 archives of the project 
dependencies? This folder could be committed with the project source code.

The yarn package manager, for example, has a similar feature:
https://yarnpkg.com/blog/2016/11/24/offline-mirror/

On Tuesday, February 20, 2018 at 6:20:54 PM UTC+1, Russ Cox wrote:
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Bourgon]

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 is optional in the sense that
consumers can still lock to package foo at v2.3.4 if it lives in plain
github.com/user/foo, but that lock will be expressed in the so-called
psuedoversion form "v0.0.0-timestamp-revhash".



On Tue, Feb 20, 2018 at 4:56 PM, Jon Calhoun  wrote:
> 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 Cox wrote:
>>
>> Hi everyone,
>>
>> I have a new blog post you might be interested in.
>> https://research.swtch.com/vgo.
>>
>> I'll try to watch this thread to answer any questions.
>>
>> Best,
>> Russ
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Brian Slesinsky]

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 order, but if it isn't done (either 
manually or automatically) nobody will use the new version except new 
customers of the patched library.

I suppose a minimal approach would be to encourage people to run "vgo get 
-u" periodically, test, and commit.

On Tuesday, February 20, 2018 at 9: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 try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jon Calhoun]

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 Cox wrote:
>
> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[s]

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 this when making breaking changes, or is it that vgo 
will handle this for users behind the scenes?

Second, I'd like to understand the proposed workflow when one repo has many 
subpackages that should be independently versioned. For example, a repo 
might have a exp/ subdirectory for experimental libraries that are 
available for adventurous users. Git tags can only identify the version of 
the whole repo; how will library maintainers signal that different packages 
have different versions?

I think the exp/ case is important but not the only case worth thinking 
about. It's also important in repos that provide both an installable main 
package and library code, like github.com/golang/protobuf. They might want 
to use tags and releases for distributing their binary, and might want to 
make breaking changes to their command-line API without a breaking version 
bump for the libraries, or vice-versa.

On Tuesday, February 20, 2018 at 9: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 try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Russ Cox]

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 tell whether vgo includes that
>functionality or not. We would want to do it at the monorepo level: ie.
>*everything* should use our forked version of the `glog` and `protobuf`
>packages.
>
> You can do that. See research.swtch.com/vgo-tour and ^F for 'myfork'.

>
>- For our (go monorepo) usecase: do you envision a single go.mod file
>being placed at the root, or would we sprinkle them as needed for each
>sub-project in the monorepo? Does vgo search upward for go.mod files?
>
> Yes, it sounds like you'd want one in the root, which would apply to all
subdirectories (until hitting another). Vgo searches upward.

>
>- More details on the zipfile module representation will be welcome.
>
> That'll be Thursday. Sorry, there's a lot to write, but it's on its way.
:-)
If you want to poke around, look in $GOPATH/src/v/cache.

>
>- Getting rid of GOPATH is nice. Where will `vgo install` drop
>binaries?
>
> You don't have to work in GOPATH, but GOPATH will stick around as a way to
control where the cached downloaded source code lives. Most users won't
need to worry since it now defaults to $HOME/go, so no one has to set it.

For now I decided to try having vgo install commands to $GOPATH/bin,
since most people will already have it in their path and it is Go-specific.
As with just about everything, it's subject to change if we discover
problems,
but it's been that way for, oh, 4 hours and it seems to be working OK so
far.
Of course, if $GOBIN is set, then that wins, as it always has.

Best,
Russ

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Zellyn]

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 it at the monorepo level: ie. 
   *everything* should use our forked version of the `glog` and `protobuf` 
   packages.
   - For our (go monorepo) usecase: do you envision a single go.mod file 
   being placed at the root, or would we sprinkle them as needed for each 
   sub-project in the monorepo? Does vgo search upward for go.mod files?
   - More details on the zipfile module representation will be welcome.
   - Getting rid of GOPATH is nice. Where will `vgo install` drop binaries?
   
Thanks for your work on this. It looks very “Go-ish”. Interested to learn 
more.

Zellyn

On Tuesday, February 20, 2018 at 12:20:54 PM UTC-5, Russ Cox wrote:
>
> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.