Re: [go-nuts] Go Programming Language Course

[prades . marq]

Wasn't Sqlite compiled to Go or something? I remember some news about it, 
using C to Go compiler. 

As for the C toolchain for Go, the easiest way to get started on Windows is 
to install MSYS2 and use pacman to install GCC 64 and then libs like 
sqlite2 .

Le mercredi 21 février 2018 21:49:50 UTC+10:30, Jonathan Yu a écrit :
>
> I develop Go on Windows 10, and it's bearable, but not great. There are 
> missing features (IIRC, plugins only work on Linux/Mac OS) and the lack of 
> a C compiler toolchain can cause problems too (e.g. I couldn't install 
> SQLite as it's a Go binding to C code, and I don't have GCC configured. I 
> guess I could've spent more time figuring out mingw32 but I just gave up.)
>
> I do think Visual Studio Code and Go (whether on Windows or Linux) is a 
> decent experience especially for simple programs that might be typical in a 
> course. That said, Linux experience is probably a good idea for students in 
> general as that's where the industry seems to be moving (at least in the SF 
> Bay Area.) Students might do well to have exposure to both as it means 
> they're not relying on central infrastructure, which might get overloaded, 
> particularly when it gets close to assignment deadlines.
>
> On Wed, Feb 21, 2018 at 5:51 AM, Dick Seabrook  > wrote:
>
>> I'm putting together a 3-credit introduction to the Go programming 
>> language at 
>> the community college level. I will create (as a minimum) syllabus, 
>> outline, 
>> lecture notes, handouts, assignments, projects, quizzes and final exam. I 
>> will
>> probably start with the Donovan & Kernighan A-W 2015 text.
>> Prerequisite: familiarity with personal computers and at least one 
>> programming
>> language, preferably C.
>> I'd like to set it up in a shared Linux environment although I'll be 
>> teaching
>> exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on 
>> campus
>> so the Linux base is do-able, however is there any value in teaching Go on
>> Windows 10 natively?
>>
>> Any thoughts or suggestions?
>> Thanks,
>> Dick S.
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Jonathan Yu / *@jawnsy* on LinkedIn , 
> Twitter , GitHub , 
> Facebook 
> *“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* — 
> Samuel Beckett, Worstward Ho (1983) 
>
> “In an adaptive environment, winning comes from adapting to change by 
> continuously experimenting and identifying new options more quickly and 
> economically than others. The classical strategist's mantra of sustainable 
> competitive advantage becomes one of serial temporary advantage.” — 
> Navigating 
> the Dozens of Different Strategy Options 
> 
>  (HBR)
>

-- 
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 Programming Language Course

[Egon]

The main value is not adding complexity in your learning setup.
As value points you can show examples how to cross-compile from Windows to 
Linux.

Of course, as Jonathan mentioned compiling with C is bit annoying.

If you just need to use CGO, then TDM-GCC does a decent job.

If you need to link to existing libraries then you need MSYS2.
Which, has a bit more complicated setup.

On Wednesday, 21 February 2018 16:25:38 UTC+2, Dick Seabrook wrote:

> I'm putting together a 3-credit introduction to the Go programming 
> language at 
> the community college level. I will create (as a minimum) syllabus, 
> outline, 
> lecture notes, handouts, assignments, projects, quizzes and final exam. I 
> will
> probably start with the Donovan & Kernighan A-W 2015 text.
> Prerequisite: familiarity with personal computers and at least one 
> programming
> language, preferably C.
> I'd like to set it up in a shared Linux environment although I'll be 
> teaching
> exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on 
> campus
> so the Linux base is do-able, however is there any value in teaching Go on
> Windows 10 natively?
>
> Any thoughts or suggestions?
> Thanks,
> Dick S.
>
>

-- 
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] What's the best way to maintain a package repository that have the major version in the import path?

[alex . rou . sg]

I don't think changing the module name would be a good idea for singletons 
tho. 
And having a v0 has the added benefit of using newer codes while 
maintaining backwards compatible API.
So no more backporting and all the mess of having multiple branches.

On Thursday, February 22, 2018 at 1:49:53 PM UTC+8, Sam Whited wrote:
>
> On Wed, Feb 21, 2018, at 22:35, alex@gmail.com  wrote: 
> > vgo suggested that package developers put the major version into the 
> import 
> > path e.g. foo/v1. 
> > However dealing with a VCS like git, this thought occur to me, what 
> would 
> > it look like when the project needs to move from v1 to v2? 
>
> This wasn't clear to me either, but it was pointed out that you can just 
> change the "module" line in your go.mod file, eg. 
>
> module "example.net/mypackage/v2" 
>
> and you don't have to actually create a /v2 tree or move your code around 
> at all. 
>
> —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

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

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

[Sam Whited]

On Wed, Feb 21, 2018, at 22:35, alex.rou...@gmail.com wrote:
> vgo suggested that package developers put the major version into the import 
> path e.g. foo/v1. 
> However dealing with a VCS like git, this thought occur to me, what would 
> it look like when the project needs to move from v1 to v2?

This wasn't clear to me either, but it was pointed out that you can just change 
the "module" line in your go.mod file, eg.

module "example.net/mypackage/v2"

and you don't have to actually create a /v2 tree or move your code around at 
all.

—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] What's the best way to maintain a package repository that have the major version in the import path?

[alex . rou . sg]

vgo suggested that package developers put the major version into the import 
path e.g. foo/v1. 
However dealing with a VCS like git, this thought occur to me, what would 
it look like when the project needs to move from v1 to v2?

In git we can rename the file in the entire history which messes things up 
for everyone so that's a bad thing to do. 
We can also copy paste v1 into the v2 folder, but then we lose the entire 
history of the files and would need to refer to the history of the other 
folder so this is a huge pain.
We can also create a dummy repository that just submodules v1 and v2 to the 
actual source repository but this isn't pretty and feels kinda hackish.
I also thought maybe do all development on v0 and then have v1/v2/etc... 
just be wrappers to v0.

The last one makes the most sense to me, so I guess question is, is there a 
better way to handle multiple API version paths? Especially when there are 
many sub packages in the same repository. 

-- 
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] Assign a new value to an already initiated variable in template

[whut . wuming]

Thanks for this example!
I realized that to modify a variable I have to add a "var" function to 
return pointer of an object,  then I can use a "set" function to modify it.
And in the beginning I also provided "get" function to return the value 
referenced by the pointer, however later I suddenly found that I don't need 
to do that, go template will automatically return the object itself, rather 
than the pointer.
So this is my version https://play.golang.org/p/C1MtTKvdmGT
I think it is more concise and elegant than the original example :-)
Thanks so much for inspiring me!


On Thursday, October 10, 2013 at 7:52:20 PM UTC-7, Steven Blenkinsop wrote:
>
> You could do something like this if you had to:
> http://play.golang.org/p/SufZdsx-1v
>
>
> On Thu, Oct 10, 2013 at 8:18 AM, Accipiter Nisus  > wrote:
>
>>
>> Templates aren't the place for doing complex logic. Do it before you pass 
>>> the data to the template.
>>>
>> Whether or not assigning a new value to a variable is considered complex 
>> logic might be up for discussion.
>>
>> When the template package is used in a generic context (eg. Executing an 
>> arbitrary template file with an arbitrary json file), you might not have 
>> the luxury of doing precalculations.
>>
>> /ANisus
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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] Go += Package Versioning

[David Anderson]

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: "upgrade all my *direct* dependencies to their latest
>> version, but keep using minimal versions below that." I don't believe there
>> is an analog to this operation in the worlds of `go get` or `dep`, but I
>> think it might be an interesting middle-ground. I as the apex module
>> developer want to say "I'd like to use the latest versions of the things
>> I'm programming against, but I don't care about *their* dependencies –
>> please defer to the library authors's opinions for those."
>>
>> First of all, am I reading correctly that this is not currently one of
>> the options you described? If so, do you think this additional option has
>> merit, compared to "upgrade the entire transitive closure to the absolute
>> newest things" ?
>>
>
> I think this operation is algorithmically trivial: Just bump the versions
> in A's list to the newest ones available of each direct dependency. I
> understand Russ' Article to justify that these operations can be
> implemented efficient and that thus a trivial operation isn't interesting
> to mention.
>

Agreed, from the algorithmic perspective it simplifies down to the existing
operation add/remove operations, so the algorithms and properties are
unchanged.

What I'm arguing for (or at least, asking about), is whether `vgo get -u`
should only set direct dependencies to the latest version, or the entire
transitive closure. It's purely a UI/UX question, not an algorithms one.

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 features/fixes, please use them," and not "I want to use the
latest possible code the universe can offer me, throughout the stack."

I believe both operations have their place, and I could be convinced either
way on which should be the default for "update my stuff." I'm wondering if
I'm alone in thinking that "upgrade only direct dependencies, minimal
versions elsewhere" is desirable as a "suggested" commandline action.

- Dave


>
> If the "import compatibility rule" is true, there shouldn't be a downside
> to do a full, transitive closure upgrade either and if this is the
> standard/most common/only way to do upgrades, that would at least build
> *some* force into the system, to progress through upgrades regularly.
>
>
>

-- 
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] Go += Package Versioning

['Axel Wagner' via golang-nuts]

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, but keep using minimal versions below that." I don't believe there
> is an analog to this operation in the worlds of `go get` or `dep`, but I
> think it might be an interesting middle-ground. I as the apex module
> developer want to say "I'd like to use the latest versions of the things
> I'm programming against, but I don't care about *their* dependencies –
> please defer to the library authors's opinions for those."
>
> First of all, am I reading correctly that this is not currently one of the
> options you described? If so, do you think this additional option has
> merit, compared to "upgrade the entire transitive closure to the absolute
> newest things" ?
>

I think this operation is algorithmically trivial: Just bump the versions
in A's list to the newest ones available of each direct dependency. I
understand Russ' Article to justify that these operations can be
implemented efficient and that thus a trivial operation isn't interesting
to mention.

If the "import compatibility rule" is true, there shouldn't be a downside
to do a full, transitive closure upgrade either and if this is the
standard/most common/only way to do upgrades, that would at least build
*some* force into the system, to progress through upgrades regularly.

-- 
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: intelliji can't access go 1.10 std lib on Mac OS

[Florin Pățan]

Hi,


You need to provide more details than this. Have you installed Go in the 
same location? What version are you using? Have you tried restarting the 
IDE after the Go install operation?

Thanks.

On Wednesday, February 21, 2018 at 1:18:22 AM UTC, Joseph Lorenzini wrote:
>
> All:
>
> I may just need to open a bug with intelliji but I find the behavior so 
> peculiar that I thought i'd ask if anyone who codes go in intelliji may 
> know what's going on.
>
> I uninstalled go 1.9.3 and installed go 1.10. After I do that, intelliji 
> can no longer find any packages in the std lib and autocomplete no longer 
> works. third party packages its fine with. I reinstalled 1.9.3 and then 
> intelliji can find the std lib again. Since I haven't upgraded intelliji, I 
> am guessing something changed in 1.10 that's breaking intelliji's ability 
> to access the std lib but I am at a loss as to how that could be.
>
> I did verify that go 1.10 install is working (e.g go version go build go 
> install all work etc)
>
> Joe 
>

-- 
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] Go += Package Versioning

[Russ Cox]

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 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] Go += Package Versioning

[David Anderson]

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
is an analog to this operation in the worlds of `go get` or `dep`, but I
think it might be an interesting middle-ground. I as the apex module
developer want to say "I'd like to use the latest versions of the things
I'm programming against, but I don't care about *their* dependencies –
please defer to the library authors's opinions for those."

First of all, am I reading correctly that this is not currently one of the
options you described? If so, do you think this additional option has
merit, compared to "upgrade the entire transitive closure to the absolute
newest things" ?


I'm still completely in love with this overall approach, and so far the
only quibbles I might have would be over syntax or equivalently unimportant
details. I sincerely hope that this becomes Go's package management
solution of choice, I'm already finding it unpleasant to operate in a world
where this isn't the way to do things :).

- Dave

On Tue, Feb 20, 2018 at 9:20 AM, 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: [golang-dev] Go += Package Versioning

[Russ Cox]

> [+cc golang-nuts, it was lost at some point]

BCC golang-nuts. Please do NOT mix the two threads. I expect that the two
different lists with different people will have different focuses for their
discussions.


On Wed, Feb 21, 2018 at 5:31 PM, Aram Hăvărneanu  wrote:

> [+cc golang-nuts, it was lost at some point]
>
> I find it unexpected that to compute a version you need information
> not from one, but from two places that use very similar but ultimately
> different syntax.
>
> In vgo the major version has to be specified in Go import paths,
> and the minor version needs to be specified in go.mod file, which
> is not Go code but looks very similar to Go code.
>
> Why not just use Go code throughout? We could extend Go syntax in
> a backwards-compatible way to be able to express all the information
> contained in the go.mod file. The bulk of the code would continue
> to import old-style, "bare", imports, while a single, or perhaps a
> small number of Go files would encode the information required for
> version management using new-style imports. Perhaps this file, or
> files could have standardized names, zmod.go, or whatever (please
> don't bikeshed the name).
>
> These files could be guarded by build-tags, so old compilers ignore
> them, just like how old compilers ignore the go.mod file.
>
> --
> 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.

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

[Aram Hăvărneanu]

[+cc golang-nuts, it was lost at some point]

I find it unexpected that to compute a version you need information
not from one, but from two places that use very similar but ultimately
different syntax.

In vgo the major version has to be specified in Go import paths,
and the minor version needs to be specified in go.mod file, which
is not Go code but looks very similar to Go code.

Why not just use Go code throughout? We could extend Go syntax in
a backwards-compatible way to be able to express all the information
contained in the go.mod file. The bulk of the code would continue
to import old-style, "bare", imports, while a single, or perhaps a
small number of Go files would encode the information required for
version management using new-style imports. Perhaps this file, or
files could have standardized names, zmod.go, or whatever (please
don't bikeshed the name).

These files could be guarded by build-tags, so old compilers ignore
them, just like how old compilers ignore the go.mod file.

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

[go-nuts] Re: How to limit what the `go get` command is able to import

[matthewjuran]

Are the builds and deployment controlled? The command “go list” can be used 
to simplify parsing the imports in each package, so a script could check 
that every import is either an allowed standard library package or one 
matching your internal URL.

Matt

On Wednesday, February 21, 2018 at 11:37:35 AM UTC-6, Brendan O'Dwyer wrote:
>
> My company wants to start using go more, and traditionally when we use 
> java and python, when we package them for the developer laptops we override 
> settings and configs for the installs to point to our internal Artifactory 
> so that we don't have developers using packages that haven't been ok'd for 
> use. I was wondering if there was anyway to do this or configure go to 
> limit what its allowed to import from the open internet with the `go get` 
> command?
>

-- 
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] Go += Package Versioning

[Henrik Johansson]

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: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 rules continue to
>> work.
>>
>
> As I understood it, the fundamental philosophical point of today's rsc
> article was that you shouldn't use the the same "name" (identifier) for two
> different "things". If you look at it from that point of view, the "v2"
> should absolutely be part of the package URL. In fact, having the concept
> of version stored in some lookaside metadata outside of the name (eg. git
> tag) would be a mistake.
>
> Zellyn
>
> --
> 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.

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

[Zellyn]

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 rules continue to 
> work. 
>

As I understood it, the fundamental philosophical point of today's rsc 
article was that you shouldn't use the the same "name" (identifier) for two 
different "things". If you look at it from that point of view, the "v2" 
should absolutely be part of the package URL. In fact, having the concept 
of version stored in some lookaside metadata outside of the name (eg. git 
tag) would be a mistake.

Zellyn

-- 
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] Go += Package Versioning

[Bakul Shah]

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.F() in one
> > package (using v1) behaves differently from foo.F() in another
> > package (using v2) as they both will have the same import path
> > and only the "bindings" in their respective go.mod change.
> 
> Agreed but it seems a bit of a rather gratuitous constraint to require the
> version to be the last element:

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 rules continue to
work.

-- 
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] Go += Package Versioning

['Axel Wagner' via golang-nuts]

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 record that I acknowledge that post to be
potentially unreasonably nitpicky :)

FWIW, I *believe* that if you only ever release v1.x.x you'll end up at
essentially the same space as today, whether you actually end up adding
breaking changes or not. Unless vgo somehow tracks API changes and verifies
that your versioning is semantic, which I can't imagine working (which was
my point then, basically). Of course this makes semantic versions largely
useless, which was my other point then.

There is one significant difference, which is that people are currently
automatically held back, whereas previously they where automatically
updated, so it's somewhat more likely that people will sleep through
necessary API changes and then break the build at an unpredictable point in
the future.

Personally, that is (with the information currently published) what I
intend to do, most likely: Tag all my stuff at v1.x.x (or maybe not tag at
all, for a "pin on first use" kinda policy) and just be careful in if and
how I break stuff.

-- 
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] Go += Package Versioning

[Sebastien Binet]

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 14:46, Henrik Johansson wrote:
> > > But wait. Wasn't there a mention of archive downloads instead of
relyin=
> g
> > 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 the path is still relavant, so you'd need a
/v2
> > directory inside the zip file, which means you probably need it in your
> > source code. However, if that is incorrect it fixes the problem.

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.F() in one
package (using v1) behaves differently from foo.F() in another
package (using v2) as they both will have the same import path
and only the "bindings" in their respective go.mod change.


Agreed but it seems a bit of a rather gratuitous constraint to require the
version to be the last element:

https://github.com/golang/go/issues/23960

I kind of like Gonum's way of versioning:
gonum.org/v1/gonum/stat
gonum.org/v1/gonum/mat
gonum.org/v1/plot/vg/vgpdf
(And, in the future:
gonum.org/v4/plot
gonum.org/v4/gonum/deeplearn
...)

-s


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

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

[Peter Bourgon]

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 Whited  wrote:
>>
>> > On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote:
>> > > But wait. Wasn't there a mention of archive downloads instead of relyin=
>> g
>> > 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 the path is still relavant, so you'd need a /v2
>> > directory inside the zip file, which means you probably need it in your
>> > source code. However, if that is incorrect it fixes the problem.
>
> As v2 is only created due to some incompatible change, in my
> view it is better to have v2 visible in the path.

·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


> Otherwise
> it is easy for a reader to get confused when foo.F() in one
> package (using v1) behaves differently from foo.F() in another
> package (using v2) as they both will have the same import path
> and only the "bindings" in their respective go.mod change.

-- 
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] Go += Package Versioning

[Bakul Shah]

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, Henrik Johansson wrote:
> > > But wait. Wasn't there a mention of archive downloads instead of relyin=
> g
> > 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 the path is still relavant, so you'd need a /v2
> > directory inside the zip file, which means you probably need it in your
> > source code. However, if that is incorrect it fixes the problem.

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.F() in one
package (using v1) behaves differently from foo.F() in another
package (using v2) as they both will have the same import path
and only the "bindings" in their respective go.mod change.

-- 
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] Go += Package Versioning

[Sam Whited]

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 coming to grips with all the implications of 
this proposal (it being a radical departure from the current state of the art), 
but the detailed posts have been very helpful; thanks for writing about it!

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

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

[Russ Cox]

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 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 server in the future?
> 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?
> Do I maintain separate branches that have a single /v2 or /v3 tree (if so,
> cherry-picking changes between them will be very difficult)?
> Do I maintain separate repos and cherry pick or copy/paste files between
> them?


> None of these sound especially appealing except perhapse having a server
> handle it for me, but this makes hosting my own packages harder.
>

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

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] Go += Package Versioning

[Henrik Johansson]

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 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 the path is still relavant, so you'd need a /v2
> directory inside the zip file, which means you probably need it in your
> source code. However, if that is incorrect it fixes the problem.
>
> —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.

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

[Henrik Johansson]

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 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) seem like they break most common source
> control work flows to me. Any time we force users to change their workflow,
> I suspect we risk having to back track later. Even in cases where it may be
> better (eg. GOPATH which, like many people, I fought against when I first
> started using Go, but later came to love) if you force developers to
> drastically change their work flow, many of them will either push back, or,
> if it's only convention as this is, simply won't do it.
>
> —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.
>

-- 
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] Go += Package Versioning

[Sam Whited]

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 the path is still relavant, so you'd need a /v2 
directory inside the zip file, which means you probably need it in your source 
code. However, if that is incorrect it fixes the problem.

—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] Ann: dep_radar - an observer for dependencies

[Rustam Zagirov]

With dep_radar you can see all versions of dependencies among applications.
Also, you can set some rules for dependencies:

   - obligation to have some library
   - recommended version (>=0.8.0, or =0.8.0) 
   - compulsion to have version, but not a hash
   - absence of some lib in a project

For now, dep_radar support this package managers: dep and glide. Supported 
code repositories: github.com or your local private bitbucket
Also, you can extend it. Feel free to create a pull request 

It's a toolkit, but it can render a colorful table with current versions of 
dependencies.

https://github.com/stamm/dep_radar

-- 
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] Go += Package Versioning

[Sam Whited]

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 server in the future?
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?
Do I maintain separate branches that have a single /v2 or /v3 tree (if so, 
cherry-picking changes between them will be very difficult)?
Do I maintain separate repos and cherry pick or copy/paste files between them?

None of these sound especially appealing except perhapse having a server handle 
it for me, but this makes hosting my own packages harder.

—Sam

-- 
Sam Whited
s...@samwhited.com

-- 
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] Go += Package Versioning

[Peter Bourgon]

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 the 
> import path be modified and rewritten by a package server in the future?

No.

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

> Do I maintain separate branches that have a single /v2 or /v3 tree (if so, 
> cherry-picking changes between them will be very difficult)?
> Do I maintain separate repos and cherry pick or copy/paste files between them?

Both of these also seem possible, at first glance.

> None of these sound especially appealing except perhapse having a server 
> handle it for me, but this makes hosting my own packages harder.
>
> —Sam
>
> --
> Sam Whited
> s...@samwhited.com
>
> --
> 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.

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

[Zellyn]

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 such as gopkg.in, will 
> the import path be modified and rewritten by a package server in the 
> future? 
> 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? 
> Do I maintain separate branches that have a single /v2 or /v3 tree (if so, 
> cherry-picking changes between them will be very difficult)? 
> Do I maintain separate repos and cherry pick or copy/paste files between 
> them? 
>
> None of these sound especially appealing except perhapse having a server 
> handle it for me, but this makes hosting my own packages harder. 
>
> —Sam 
>

Maintaining fixes on two different branches doesn't seem much easier. I 
guess you could cherry-pick the same commit onto both branches, if it 
worked. With both versions visible in the same repository, you can send one 
PR that applies the same fix in two places, which is nice for review.

I guess every approach has pros and cons. vgo seems particularly goish :-)

Zellyn 

-- 
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] Go += Package Versioning

[Sam Whited]

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) seem like they break most common source 
control work flows to me. Any time we force users to change their workflow, I 
suspect we risk having to back track later. Even in cases where it may be 
better (eg. GOPATH which, like many people, I fought against when I first 
started using Go, but later came to love) if you force developers to 
drastically change their work flow, many of them will either push back, or, if 
it's only convention as this is, simply won't do it.

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

Re: [go-nuts] Re: ANN: gijit, a Go interpreter

[Jason E. Aten]

I've released gijit v1.0.0.  This brings over the full typesystem from 
GopherJS's implementation into the gijit LuaJIT environment.
I ported it to windows, and added complex number support.

https://github.com/gijit/gi

Release v1.0.0 of *gijit* marks these milestones:

   - the full program _bench/mul.go (mat_test 501) builds and runs; with no 
   imported packages used.
   - gijit has much improved complex number support.
   - gijit runs on Windows now, as well as OSX and Linux.

Limitations not yet addressed:

   - import of packages (e.g. import "fmt") on linux doesn't appear to be 
   working. #27
   - imports of binary Go packages in general need some help. Issue #21
   - chan/select/goroutines are not implemented; init() functions and full 
   ahead-of-time compile of packages is not done.

-- 
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] How to limit what the `go get` command is able to import

[brendan . p . odwyer]

My company wants to start using go more, and traditionally when we use java 
and python, when we package them for the developer laptops we override 
settings and configs for the installs to point to our internal Artifactory 
so that we don't have developers using packages that haven't been ok'd for 
use. I was wondering if there was anyway to do this or configure go to 
limit what its allowed to import from the open internet with the `go get` 
command?

-- 
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] Go Programming Language Course

[Jonathan Yu]

I develop Go on Windows 10, and it's bearable, but not great. There are
missing features (IIRC, plugins only work on Linux/Mac OS) and the lack of
a C compiler toolchain can cause problems too (e.g. I couldn't install
SQLite as it's a Go binding to C code, and I don't have GCC configured. I
guess I could've spent more time figuring out mingw32 but I just gave up.)

I do think Visual Studio Code and Go (whether on Windows or Linux) is a
decent experience especially for simple programs that might be typical in a
course. That said, Linux experience is probably a good idea for students in
general as that's where the industry seems to be moving (at least in the SF
Bay Area.) Students might do well to have exposure to both as it means
they're not relying on central infrastructure, which might get overloaded,
particularly when it gets close to assignment deadlines.

On Wed, Feb 21, 2018 at 5:51 AM, Dick Seabrook 
wrote:

> I'm putting together a 3-credit introduction to the Go programming
> language at
> the community college level. I will create (as a minimum) syllabus,
> outline,
> lecture notes, handouts, assignments, projects, quizzes and final exam. I
> will
> probably start with the Donovan & Kernighan A-W 2015 text.
> Prerequisite: familiarity with personal computers and at least one
> programming
> language, preferably C.
> I'd like to set it up in a shared Linux environment although I'll be
> teaching
> exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on
> campus
> so the Linux base is do-able, however is there any value in teaching Go on
> Windows 10 natively?
>
> Any thoughts or suggestions?
> Thanks,
> Dick S.
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

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

Re: [go-nuts] what was learned from the dep experiment

[Ian Lance Taylor]

On Wed, Feb 21, 2018 at 6:19 AM, Joseph Lorenzini  wrote:
>
> So I read Russ Cox post and specifically noted this:
>
> "But once we understand the design space better and can narrow it down to
> the few key features that must be supported, it will help the Go ecosystem
> to remove the other features, to reduce expressiveness, to adopt enforced
> conventions that make Go code bases more uniform and easier to understand
> and make tooling easier to build."
>
>
> And here's Sam Boyer:
>
> "It [vgo] was created largely in isolation from the community’s work on dep,
> to the point where not only is there no shared code and at best moderate
> conceptual overlap, but a considerable amount of the insight and experience
> gleaned from dep as the “official experiment” is just discarded."
>
>
> I don't have an attachment to vgo or dep one way or another. Package
> management is complicated. I don't believe there's a "right" answer so much
> as balancing tradeoffs. Someone is going to be upset that you don't support
> their specific workflow. But there's been very little explanation to the
> community about why the things dep did at a high level were thrown out.
>
> I am curious to know what those are.

I think Russ explained that fairly clearly in
https://research.swtch.com/vgo-intro , particularly in the section "An
Official Package Management Experiment".

Ian

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

[go-nuts] Re: intelliji can't access go 1.10 std lib on Mac OS

[matthewjuran]

Maybe something with GOROOT? From the release notes:

If the environment variable $GOROOT is unset, the go tool previously used 
> the default GOROOT set during toolchain compilation. Now, before falling 
> back to that default, the go tool attempts to deduce GOROOT from its own 
> executable path. This allows binary distributions to be unpacked anywhere 
> in the file system and then be used without setting GOROOT explicitly.


How did you install Go?

Matt

On Tuesday, February 20, 2018 at 7:18:22 PM UTC-6, Joseph Lorenzini wrote:
>
> All:
>
> I may just need to open a bug with intelliji but I find the behavior so 
> peculiar that I thought i'd ask if anyone who codes go in intelliji may 
> know what's going on.
>
> I uninstalled go 1.9.3 and installed go 1.10. After I do that, intelliji 
> can no longer find any packages in the std lib and autocomplete no longer 
> works. third party packages its fine with. I reinstalled 1.9.3 and then 
> intelliji can find the std lib again. Since I haven't upgraded intelliji, I 
> am guessing something changed in 1.10 that's breaking intelliji's ability 
> to access the std lib but I am at a loss as to how that could be.
>
> I did verify that go 1.10 install is working (e.g go version go build go 
> install all work etc)
>
> Joe 
>

-- 
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] Go Programming Language Course

[Dick Seabrook]

I'm putting together a 3-credit introduction to the Go programming language 
at 
the community college level. I will create (as a minimum) syllabus, 
outline, 
lecture notes, handouts, assignments, projects, quizzes and final exam. I 
will
probably start with the Donovan & Kernighan A-W 2015 text.
Prerequisite: familiarity with personal computers and at least one 
programming
language, preferably C.
I'd like to set it up in a shared Linux environment although I'll be 
teaching
exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on 
campus
so the Linux base is do-able, however is there any value in teaching Go on
Windows 10 natively?

Any thoughts or suggestions?
Thanks,
Dick S.

-- 
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] Go += Package Versioning

[sam boyer]

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 than is wise.

On Tuesday, February 20, 2018 at 1:55:59 PM UTC-5, David Anderson wrote:
>
> 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 informally is that 
> traditional "arbitrary version selection" algorithms create the wrong 
> incentive structure for library authors, in the sense that they have all 
> the power to lock versions arbitrarily, but bear none of the pain 
> associated with their decisions - instead, the binary author at the apex of 
> the dependency tree gets that pain. "Authority without responsibility" is 
> the death of many incentive structures.
>
> 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.
>
> Questions that arose during reading:
>
>- In the "defining Go modules" section, you say: "Although semantic 
>versions are strongly preferred, referring to specific commits will be 
>supported as well." Then, you specify that such commits order before 
>v0.0.0. To me, this suggests that this feature will be useless, because 
> any 
>non-trivial example will have *some* semver constraint somewhere in 
>the dependency tree, such that in practice commit-hash versions will 
> always 
>be overridden by minimal version selection. I don't have a solution to 
> this 
>(other than removing support for commit-hash versions), but it seems like 
>it's something to think about
>   - One alternative I considered, but discarded, was to order all 
>   tags and commits by their date, and run minimal version selection on 
> that. 
>   However, this doesn't work because semver tag dates don't grow 
>   monotonically - you might have 0.1.2 released after 0.2.0, which leads 
> to 
>   confusing behavior to the user - why did 0.2.0 get selected when 0.1.2 
> was 
>   a "better" minimal version?
>- Modules as zip archives: how do I discover which versions are 
>available? Minimal version selection seems to rely on being able to list 
>the version continuum for a module, so that constraints can be applied. 
>What's the expected way to do that?
>- Writing module files sounds like a job for a machine, in cases where 
>I don't care which version gets used. Can `goimports` (or a new sibling 
>tool) be taught to update module definitions based on my code?
>- No GOPATH required: YES! Thank you. I share Zellyn's question on 
>what happens to `go install` in this world. Does it go away? Does it 
>install to some new $GOBINARYINSTALL or somesuch?
>
> Haven't read the vgo tour yet, it may answer some of these. I may be back 
> with more :)
>
> - Dave
>
>
> On Tue, Feb 20, 2018 at 9:20 AM, 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...@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] what was learned from the dep experiment

[Joseph Lorenzini]

All:

So I read Russ Cox post and specifically noted this:

"But once we understand the design space better and can narrow it down to 
the few key features that must be supported, it will help the Go ecosystem 
to remove the other features, to reduce expressiveness, to adopt enforced 
conventions that make Go code bases more uniform and easier to understand 
and make tooling easier to build."


And here's Sam Boyer : 

"It [vgo] was created largely in isolation from the community’s work on 
dep, to the point where not only is there no shared code and at best 
moderate conceptual overlap, but a considerable amount of the insight and 
experience gleaned from dep as the “official experiment” is just discarded."


I don't have an attachment to vgo or dep one way or another. Package 
management is complicated. I don't believe there's a "right" answer so much 
as balancing tradeoffs. Someone is going to be upset that you don't support 
their specific workflow. But there's been very little explanation to the 
community about why the things dep did at a high level were thrown out. 

I am curious to know what those are. 

Thanks,
Joe

-- 
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] simple sprintF output question

[Jakob Borg]

You’re quoting the help for %x for strings and byte slices. For integers it 
simply says "base 16, with lower-case letters for a-f” and thus behaves like 
any other number base usually does. In this case, you want “%02x”.

//jb

On 21 Feb 2018, at 12:06, David Renne 
> wrote:

https://play.golang.org/p/XZimA47p9qM

Why isnt this formatted with two bytes below 10 and is merely 0-9 instead of 
00, 01, 02 etc etc with a left padded zero?

The documentation of %x for sprintf made me think that this would keep a left 
padded zero on my string for 0-9, so I merely abstracted my sprintf to check if 
it's lower than 10 and then pad it to make it look like a proper mac address.  
I would love to come up with some better verbiage for the description in the 
documentation for 0-9 so people arent surprised and need to left pad it like I 
had to for a mac address


%x  base 16, lower-case, two characters per byte




--
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] simple sprintF output question

[David Renne]

https://play.golang.org/p/XZimA47p9qM

Why isnt this formatted with two bytes below 10 and is merely 0-9 instead 
of 00, 01, 02 etc etc with a left padded zero?   

The documentation of %x for sprintf made me think that this would keep a 
left padded zero on my string for 0-9, so I merely abstracted my sprintf to 
check if it's lower than 10 and then pad it to make it look like a proper 
mac address.  I would love to come up with some better verbiage for the 
description in the documentation for 0-9 so people arent surprised and need 
to left pad it like I had to for a mac address

%x  base 16, lower-case, two characters per byte



-- 
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] Go += Package Versioning

[Henrik Johansson]

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 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 transitive dep and it seems it indeed mixed upper and lower case.
> Does vgo assume lower case?
>
>
> ons 21 feb. 2018 kl 06:46 skrev :
>
>> 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 at 6:42:50 PM UTC-8, Dominik Honnef wrote:
>>
>>> 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 fail if dependencies
>>> are not present. Vgo seems to change this, by promising the user that
>>> dependencies will be automatically downloaded. Running `vgo build` at
>>> any point will "just work". Tools, however, do not have this luxury,
>>> for multiple reasons:
>>>
>>> - Multiple tools may run in parallel, either via helpers such as
>>> gometalinter, or simply because editors like Emacs launch multiple
>>> tools at once, for example when saving a file. This is likely prone to
>>> race conditions. File locking may be an option, but file locking is
>>> known to cause erratic problems on networked file systems, or be
>>> outright unsupported.
>>> - Fetching the dependencies, e.g. via 'vgo build', has the side-effect
>>> of modifying the go.mod file. This is probably unacceptable for tools
>>> that are run automatically, without the user's express wish to add new
>>> dependencies to the go.mod file.
>>> - If we do find a solution to these two problems, we'd probably still
>>> want a 'vgo get' (with no arguments), to just fetch the dependencies,
>>> without also incurring a costly build.
>>>
>>> In my opinion, tools should behave as closely as possible to (v)go
>>> build, so that users can operate on a single set of expectations.
>>>
>>> My second concern is regarding the promise of getting rid of the
>>> vendor directory. Reproducible builds not only depend on versioning,
>>> but also on ensuring that code doesn't go away, be it due to server
>>> downtime or more permanent reasons. Vendoring makes this rather easy:
>>> add your dependencies to vendor and commit them, and your project is
>>> now self-contained. Vgo seems to discourage this practice. Can you
>>> suggest an alternative that is as straightforward as vendoring? All
>>> other solutions - which amount to various forms of proxies and mirrors
>>> - are significantly more laboursome.
>>>
>>> I have noticed that currently, vgo downloads dependencies into GOPATH.
>>> Are there any plans to instead store them with the module itself,
>>> possibly in a way that facilitates committing them to version control?
>>>
>>> On Tue, Feb 20, 2018 at 6:20 PM, 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...@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.
>>
>

-- 
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] Go += Package Versioning

[Henrik Johansson]

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 transitive dep and it seems it indeed mixed upper and lower case.
Does vgo assume lower case?


ons 21 feb. 2018 kl 06:46 skrev :

> 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 at 6:42:50 PM UTC-8, Dominik Honnef wrote:
>
>> 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 fail if dependencies
>> are not present. Vgo seems to change this, by promising the user that
>> dependencies will be automatically downloaded. Running `vgo build` at
>> any point will "just work". Tools, however, do not have this luxury,
>> for multiple reasons:
>>
>> - Multiple tools may run in parallel, either via helpers such as
>> gometalinter, or simply because editors like Emacs launch multiple
>> tools at once, for example when saving a file. This is likely prone to
>> race conditions. File locking may be an option, but file locking is
>> known to cause erratic problems on networked file systems, or be
>> outright unsupported.
>> - Fetching the dependencies, e.g. via 'vgo build', has the side-effect
>> of modifying the go.mod file. This is probably unacceptable for tools
>> that are run automatically, without the user's express wish to add new
>> dependencies to the go.mod file.
>> - If we do find a solution to these two problems, we'd probably still
>> want a 'vgo get' (with no arguments), to just fetch the dependencies,
>> without also incurring a costly build.
>>
>> In my opinion, tools should behave as closely as possible to (v)go
>> build, so that users can operate on a single set of expectations.
>>
>> My second concern is regarding the promise of getting rid of the
>> vendor directory. Reproducible builds not only depend on versioning,
>> but also on ensuring that code doesn't go away, be it due to server
>> downtime or more permanent reasons. Vendoring makes this rather easy:
>> add your dependencies to vendor and commit them, and your project is
>> now self-contained. Vgo seems to discourage this practice. Can you
>> suggest an alternative that is as straightforward as vendoring? All
>> other solutions - which amount to various forms of proxies and mirrors
>> - are significantly more laboursome.
>>
>> I have noticed that currently, vgo downloads dependencies into GOPATH.
>> Are there any plans to instead store them with the module itself,
>> possibly in a way that facilitates committing them to version control?
>>
>> On Tue, Feb 20, 2018 at 6:20 PM, 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...@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.
>

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