Re: [go-nuts] Structured configuration in Go

[Paul Jolly]

Out of interest, have you come across CUE?

https://cuelang.org/

On Sat, 9 Apr 2022, 15:31 Andrew Pillar,  wrote:

> An article I wrote about a new configuration library I developed in Go
> for working with structured configuration.
>
> Article:
>
> https://andrewpillar.com/programming/2022/04/09/structured-configuration-in-go/
> Repo: https://github.com/andrewpillar/config
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cce0eeb5a085f6c7539774790d813cef254a4a0b.camel%40andrewpillar.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6GYwM7JDd9dw%3DTCoL_i-OH%2BVUmN4cymsTMqboz1Fp72w%40mail.gmail.com.

Re: [go-nuts] Re: Should dev tools be tracked by go.mod?

[Paul Jolly]

I have nothing to add to Sean's excellent reply, other than to mention...

> Most of my experience has been with external tooling, and here I prefer using 
> `go install pkg@version`
> over pinning with go.mod as this ensures no interference in dependency 
> versions between tools,
> and can be put in the same place as the other scripting that makes use of the 
> tools.

There is also `go run pkg@version` which obviates setting PATH at the
expense of slightly more command startup overhead.

Regarding that overhead, on a recent tools call Michael Matloob from
the cmd/go team mentioned they were looking into optimisations that
might reduce the overhead of `go install pkg@version`.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5LFb9_QXmb69fErCvbuHzYssJpduvGWdMJd8H6kA_frQ%40mail.gmail.com.

Re: [go-nuts] Convert a go.mod file into checked out dependencies

[Paul Jolly]

Hi Kevin,

As I replied on Gophers Slack:

go list -m all will give you information about dependencies. Add -json
to give you that in a more easily parsed format.

https://github.com/rogpeppe/gohack can be used to do what you want
with respect to checking out from VCS using the -vcs flag in
combination with the GOHACK env var appropriate set for the module in
question.


Paul

On Wed, 12 Jan 2022 at 18:58, Kevin Burke  wrote:
>
> Hi,
> Sometimes I just want to inspect third party code for a library, and/or edit 
> it.
>
> I'm looking for a tool that will read all of the dependencies in a go.mod 
> file and then check out all of the right versions of all of the source code 
> into the right places in a $GOPATH. Does that exist?
>
> Failing that, is there a tool that will read a go.mod file and give me 
> version information about each dependency? I see packages.Load, but that 
> doesn't seem super targeted for the use case; if it's the best that exists 
> then I'll probably make it work.
>
> Kevin
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/18fca322-5913-4cc8-bbd3-fc84f4f0e673n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7R8%3DikgwUL%3DxGaL%3D7_-o6NMPcHK_-a28nO2m1KvrM58g%40mail.gmail.com.

Re: [go-nuts] Accidentally released a v1.0.0 for my package, how do I go back from there here?

[Paul Jolly]

Module retraction gives you a way of "undoing" the release.

There is a "Play with Go" guide on the topic:
https://play-with-go.dev/retract-module-versions_go116_en/ (the guide
can be read without needing to use the interactive terminal)

Also the reference documentation for the retract directive:
https://golang.org/ref/mod#go-mod-file-retract

On Fri, 30 Apr 2021 at 22:57, Astha Jain  wrote:
>
> Hello,
> I accidentally created a release v1.0.0 for my public package, and it is not 
> cached in module cache.
>
> I deleted the release from git and created a new 0.x release for the package. 
> but when I do go get ..@latest, I still get 1.0.0 version.
>
> How do I go back?
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d83425f3-e4ca-4032-8181-01c0fc8848b9n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7LZ1wECJuHENzk54mqrs0%3DZi_g50rAm2odOSwd6gykNA%40mail.gmail.com.

Re: [go-nuts] go install, replace directive any ongoing discussions?

[Paul Jolly]

>> I missed the conversation originally. however go install has been left in a 
>> unfortunate state where it bewilderingly errors out when the main module 
>> contains a replace directive.
>
> This sounds like a bug. I would file an issue with an easy reproduction case.

Erroring on replace directives is an intentional decision for now:
https://github.com/golang/go/issues/40276#issue-659471259

But might be relaxed in the future:

> Parts of this proposal are more strict than is technically necessary (for
> example, requiring one module, forbidding replace directives). We could relax
> these restrictions without breaking compatibility in the future if it seems
> expedient. It would be much harder to add restrictions later.

If you think this is a valid case for requiring non-directory replace
directives to be applied, then I suggest raising an issue with some
details.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7-b91t0oSNHpYQzUqr9apj9Zo14aXX0dEMd-5dK%3DkhPQ%40mail.gmail.com.

Re: [go-nuts] `go list` across multiple modules?

[Paul Jolly]

> I just can't figure out how to do this.  Maybe it can't be done in `go
> list` ?  Or maybe we're just missing some detail of go modules..

go list operates in the context of a single module (in the mode you
are interested in), so you cannot do this with a single command across
multiple modules.

> First I do a `find` for any file that has a specific comment tag,
> indicating that the package needs codegen.  The results span several
> of the in-repo submodules.

Just to check, I'm assuming the results of this find command are being
translated to a list of packages? Because the transitive dependencies
of a list of packages within a module can be done via a single go list
command.

> For each target package, I want to get the list of all deps and
> extract the GoFiles.  Then I can use that to determine if the codegen
> needs to run.

FWIW I wrote a tool to do just this:
https://pkg.go.dev/myitcv.io@v0.0.0-20201125173645-a7167afc9e13/cmd/gogenerate
which might work in your situation.

> Where it breaks down is that I can't seem to `go list` all at once:
>
> ```
> # This works within the "root" module
> $ go list -f '{{.GoFiles}}' ./subdir
> [file.go]

This will work.

> # This does not work across modules
> $ go list -f '{{.GoFiles}}' ./submod/used ./submod/unused
> main module (example.com/m) does not contain package example.com/m/submod/used
> main module (example.com/m) does not contain package 
> example.com/m/submod/unused

Per above, this will not work across module boundaries.

> # Nor does this work, even with module replacements
> $ go list -f '{{.GoFiles}}' ./staging/src/example.com/other1/used
> ./staging/src/example.com/other1/unused
> main module (example.com/m) does not contain package
> example.com/m/staging/src/example.com/other1/used
> main module (example.com/m) does not contain package
> example.com/m/staging/src/example.com/other1/unused
> ```

With replace directives in place this should work, but you won't be
able to use the relative path to the modules (which is in fact
interpreted as a directory): it will need to be the full
module/package path.

> I can run `go list` multiple times, but that's INCREDIBLY slow - most
> of these submodules have common deps that are large.  This re-parses
> everything over and over.  It takes almost 60 seconds just to do `cd
> $dir; go list` (on the real kubernetes repo).

Do you have a repro of this taking 60 seconds? Because that really
shouldn't be the case with a populated local module cache.


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn77v8KiJWmJFQZOmDKAt7zwAP7yDrxG-yTMS_JodQaGyA%40mail.gmail.com.

Re: [go-nuts] How to use packages and modules with git repositories on private servers

[Paul Jolly]

We created a guide that looks to introduce this topic as part of the
Play with Go launch a couple of weeks ago:

https://play-with-go.dev/working-with-private-modules_go115_en/

I'd certainly be interested in any feedback you have on that guide,
given the detailed response you wrote.

Thanks

On Wed, 9 Dec 2020 at 02:31, Dean Schulze  wrote:
>
> I couldn't get the information I needed when I posted this question on a 
> couple of forums, so I've posted a detailed explanation of how to use 
> packages and modules with git repositories on private servers.
>
> I hope this helps anyone else who finds themselves in this situation.
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a058c330-eb22-41a1-88ba-7208d815cac1n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn59ZPTcm2Nc8YaF0YVM2KuDOk684zNg6p71rMf%2BJVuRWQ%40mail.gmail.com.

Re: [go-nuts] Online service to run Go code with Go modules support

[Paul Jolly]

Hi,

> Hi go devs. I am thinking about brining up a service that would execute Go 
> code with support of third party modules, so that both Go modules developers 
> and users could play with a code and get immediate results without having any 
> Go environment, through a browser.
> I've noticed that there are some similar services in the scene right now, 
> including goplay.space and play.golang.org but they seems do not support 
> third party modules usage.

play.golang.org does support third party modules, at least importing
them: https://play.golang.org/p/2dHQwOa7_gn

On a related note, last week we released https://play-with-go.dev/
which is designed to provide people with an interactive introduction
to the tooling required to work with the Go programming language. The
authentication is required because each guide instance is connected to
a remote container which effectively gives you a full blown
development environment in the browser alongside the guide (there is
even the option for us to serve VSCode in a similar way, allowing the
user to edit files in the remote session). But as
https://play-with-go.dev/go-fundamentals_go115_en/ demonstrates, not
only does it provide you with a complete development environment, but
guides are automatically provisioned with remote source code
repositories as required. So you interactively follow the publishing
of a real module, that is then resolved via the proxy.

> PS Additionally there might my different OS support ( Linuxes distros ) so 
> that code would be executed on respected dockers with targeted OS internally, 
> for people doing arch dependent applications.

With play-with-go.dev we have also explored the possibility of the
user choosing the platform on which the guide should run, which would
also vary the commands needed to run the guide as necessary.

If play-with-go.dev is of any interest I'd be happy to talk about that
more (it's an open source project, supported by sponsorship)


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6pdz228J7s0%3D8sd-tTYNjhTVUmPG%2BH23YyPaA4C_Y9Dg%40mail.gmail.com.

Re: [go-nuts] Re: Generating code into module cache?

[Paul Jolly]

> Mostly trying to improve the UX by avoiding generated code clutter during 
> development. I concede that storing all your generated code in one directory 
> inside your project isn't that big of a deal. Another solution could be to 
> configure your editor to hide the generated directory.

Either that or, assuming you have some sort of visual tree view, to
show generated files in italics or some such. Or to have generated
files not be included in fuzzy finder results. There are many
approaches.

> Yah, exactly. The CLI wraps "go run" anyway, so there's a place to generate 
> code on new machines before starting the program.

So this is a tool you are writing for other developers? I'm further
assuming the generated code is critical to code they are then writing.
If so, this surely must be committed with whatever code they are
writing? In which case, generating this to anywhere other than the
place where they are writing code is a problem. But then I might have
totally misunderstood what you are doing here, in which case can you
explain a bit more?

> > In which case replace directives with a directory target is most likely 
> > your best solution:
>
> Replace is an interesting idea. I think replace would work well if there was 
> a standard place to put generated code outside of your project. I guess 
> that's what I'm looking for: a standard place to hide away generated code 
> until you care about it and want to vendor it. And when you do want to vendor 
> it, you can use the same code paths as your third-party dependencies.

There is nothing stopping you coming up with your own convention here,
or indeed retaining the convention of using
GOPATH/src/github.com/my/repo etc. Tools like gohack
(https://github.com/rogpeppe/gohack) do just that: establish a
convention.


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5oN6AkcTn9_qo5H3H868100D6Qqzry5mNO%2Ba-3M%3DK4Ng%40mail.gmail.com.

Re: [go-nuts] Re: Generating code into module cache?

[Paul Jolly]

I would personally steer clear of writing anything to the module cache.

If you are only code generating into the module cache and not
publishing this generated code, by definition that generated content
will not be available remotely. Hence any code you publish that
depends on this generated content will fail to resolve. So we are
talking local development only.

In which case replace directives with a directory target is most
likely your best solution:

https://golang.org/ref/mod#go-mod-file-replace

On Wed, 21 Oct 2020 at 00:12, 'Axel Wagner' via golang-nuts
 wrote:
>
> On a second read, I probably misunderstood what you intend to do.
> I still think what you intend to do might technically be possible - I'm not 
> entirely sure, though. The module cache is by default read-only, so you'd 
> want a tool that force-replaces a directory. And then, the go build cache 
> might get confused, if the contents of the cache change. I'd also predict 
> that you regularly run into issues where things don't build the same on your 
> machine as for other people, leading to hard to debug and confusing errors. 
> And, lastly, I'm not sure what the advantages would be over doing the normal 
> approach of generating the files and committing them? It seems strictly more 
> work, with no added benefits.
>
> On Wed, Oct 21, 2020 at 1:06 AM Axel Wagner  
> wrote:
>>
>> Technically, I think this would be possible. Your code wouldn't be usable 
>> together with code that doesn't use modules. And you'd need to have a server 
>> that takes the code from the git repository and generates a .zip file for 
>> any interesting version (possibly on demand), which you would probably have 
>> to build yourself. It also means there is no reliable provenance from your 
>> git repository to your published module, so reproducing/forking what you do 
>> might be more difficult. Code analysis running from the repository (like 
>> sourcegraph or githubs hover info) might not understand the code anymore.
>>
>> But, yeah. In general, you can put *any* go code in an appropriate .zip-file 
>> and serve it up as a module. You don't even have to publish the repository 
>> itself at all, if you so wish.
>>
>> On Wed, Oct 21, 2020 at 12:39 AM Matt Mueller  wrote:
>>>
>>> Sorry, maybe cache is the wrong word.
>>>
>>> Wherever "go get -u ..." downloads modules, I'd like to stick my generated 
>>> code.
>>>
>>> Conceptually you could think of it as a virtual module used only during 
>>> development. If you're familiar with Node.js, You could also think of it as 
>>> creating a directory in node_modules/ and then importing it with 
>>> require(...).
>>>
>>> I'm just wondering if I'll run into issues doing this or mess up other 
>>> people's modules.
>>>
>>> On Tuesday, October 20, 2020 at 9:22:05 PM UTC+2 seank...@gmail.com wrote:

 That doesn't really make sense?
 The module cache is for immutable versions of modules,
 ie. publish your (generated) code as a package/module, import that
 it will then get cached

 On Tuesday, October 20, 2020 at 8:50:25 PM UTC+2 mattm...@gmail.com wrote:
>
> Hey folks,
>
> I'm working on a project with a lot of code generation. I'd love to:
>
> - get the code generation out of the way when you don't care about it
> - be able to vendor the generated code when you do care about it
>
> That led me to an idea about generating code into the go module cache. Do 
> you see any downside in doing this?
>
> Thanks!
> Matt
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/a26c4aca-bbe3-4dc5-9f66-09d1db521517n%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF36cBaAhuxPqTK3dbF6tja3yVAYrcNaWkMsw%3D8LR_-Pw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn58BahT2nH3hywgqkENHe0-YCJsTsey6YR2saHjtQuppg%40mail.gmail.com.

Re: [go-nuts] how to use replace directives in go.mod in dev but not prod

[Paul Jolly]

> CI probably is the anwser, made a utility based on golang.org/x/mod which 
> parses go.mod and checks if replaces are there and exit with error state if 
> they are.

This isn't the problem discussed in 26640 at least. There, the issue
is that it is not currently possible to have a go.mod.local file
_outside_ of source control that augments the real go.mod.

Your suggestion is covered by the gorelease tool
(https://pkg.go.dev/golang.org/x/exp/cmd/gorelease)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7rEfxeniccZB2Li_d61cp0uwC0n1c_zor-eHssiBDv5w%40mail.gmail.com.

Re: [go-nuts] how to use replace directives in go.mod in dev but not prod

[Paul Jolly]

26640 is an open issue describing the same problem you're describing.
Unfortunately because it remains open there is not yet a solution.

On Tue, 22 Sep 2020, 07:36 Alex Mills,  wrote:

> i dont understand, is there a solution or just a proposal?
>
> On Mon, Sep 21, 2020, 23:03 Paul Jolly  wrote:
>
>> I just replied. I think that https://github.com/golang/go/issues/26640
>> covers this.
>>
>> On Tue, 22 Sep 2020 at 06:52, Alex Mills  wrote:
>> >
>> > I put this question on the golang issue tracker on github:
>> > https://github.com/golang/go/issues/41546
>> >
>> > I am sure it's been answered before but hard to search for..anyone know
>> what the right approach is? I like how node.js / NPM solve it using
>> symlinks personally.
>> >
>> > --
>> > 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.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/92794ec1-ee89-4c98-820e-750b1db079ffn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7BybiwHDdP48TH462AYhAEupMF_rAXxHHy8p%2BPW%3DsGqw%40mail.gmail.com.

Re: [go-nuts] how to use replace directives in go.mod in dev but not prod

[Paul Jolly]

I just replied. I think that https://github.com/golang/go/issues/26640
covers this.

On Tue, 22 Sep 2020 at 06:52, Alex Mills  wrote:
>
> I put this question on the golang issue tracker on github:
> https://github.com/golang/go/issues/41546
>
> I am sure it's been answered before but hard to search for..anyone know what 
> the right approach is? I like how node.js / NPM solve it using symlinks 
> personally.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/92794ec1-ee89-4c98-820e-750b1db079ffn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7xmOmN16bi8dyfeUdnzcHXZbRUweWeX%2B1x70-bsyoAQg%40mail.gmail.com.

Re: [go-nuts] What are the best practices for go build tools?

[Paul Jolly]

Hi Andi,

> 1) I cannot do go install tools.go:

go install takes main packages as arguments, so no, this will not
work. The tools.go file (like the example you present) is simply a way
of declaring a dependency on a main package through a file that will
never be built (hence the +build tools constraint). Even though this
file is, in normal operation, ignored by all build commands (go build,
go install etc) it _is_ seen by go mod tidy (which ignores build
constraints). Hence the requirement is considered when collating the
main module's requirements.

> instead I need to duplicate each tool installation in the Makefile

If you want to install these commands then yes, this needs to happen
somewhere (could even be a go:generate step)

However, you can simply go run $mainpkg and this will work (see below)

> 2) The internal tools are currently not installed in invoked during build:

Per my suggestion above, this is my preferred mechanism. It avoids any
unnecessary steps of ensuring the correct GOBIN, PATH etc.

> //go:generate go run ../cmd/tools/decorate.go ...
>
> This fails during cross-build:
> GOOS=linux GOARCH=arm make
> go install github.com/mjibson/esc
> go install github.com/golang/mock/mockgen
> Generating embedded assets
> go generate ./...
> ...
> fork/exec 
> /var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build741389459/b001/exe/decorate:
>  exec format error
> charger/evsewifi.go:57: running "go": exit status 1
> fork/exec 
> /var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build892585922/b001/exe/decorate:
>  exec format error
> meter/meter.go:16: running "go": exit status 1
>
> I've looked at https://golang.org/cmd/go/#hdr-Build_constraints but couldn't 
> find a description of best practices or even mention of +built tools.

I'm not sure how you are getting into this situation, because go run
will build a binary for the platform on which cmd/go is running.

Unless you have GOOS and GOARCH set, in which case the go run during
the go generate phase will be building for potentially a different
platform?


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4O%2Byg2GxWRccoMCv9wjibq9QwGsmbP0t52FqZyw5Jq%2Bg%40mail.gmail.com.

Re: [go-nuts] How to use "go/build".ImportDir to get Package struct?

[Paul Jolly]

Hi,

You want to be using https://pkg.go.dev/golang.org/x/tools/go/packages

The docs include an example of how to do this.

Thanks,


Paul

On Thu, 17 Sep 2020 at 12:29, Hein Meling  wrote:
>
> Hi all,
>
> I'm trying to get info about the package, but the code below returns an empty 
> build.Package struct... Anyone know how to use this API to get a populated 
> Package struct?
>
> p, err := build.ImportDir("../paging", build.FindOnly)
> if err != nil {
>   t.Error(err)
> }
> fmt.Println(p)
>
> Thanks,
> :) Hein
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/eae52a72-8e4a-40b2-aa64-f83a5024328fn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4y57K3b-5Rm%3Dk9%2BDf8quk6MrOTK314hCNeGhOT9-w7oA%40mail.gmail.com.

Re: [go-nuts] Workflow and tools for JSON Schema generation

[Paul Jolly]

CUE (https://cuelang.org/) will (in the near future) be able to help
with the Go -> JSON Schema part (or indeed JSON Schema -> Go).

Please feel free to ask any questions of the community via
https://cuelang.org/community/

On Thu, 3 Sep 2020 at 08:05, Johann Höchtl  wrote:
>
>
> Hi,
> I would like to accomplish the following:
>
> An existing golang package on github provides a struct definition I am 
> interested in to be used as part of a REST API interface I design
>
> I would like to automatically go generate json schema for this struct
> I would like to incorporate this generated schema into an OpenAPI definition 
> and generate go boilerplate for that
>
>
> For step 2 I am using https://github.com/deepmap/oapi-codegen which works 
> great. It also supports $ref to external schemas.
>
> Still looking to accomplish step 1: I am searching for a tool which go 
> generates JSON schema from a golang source file or package. Any help?
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/f0e099de-7008-478d-ba92-f2febd0c40bdn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4EgxJJc1qA53a7kZVeeXrzb%2BYvU-vgGr%2BgcxJakajhjA%40mail.gmail.com.

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

[Paul Jolly]

> That snippet is helpful, but given https://golang.org/issue/40965 I'm
> concerned user defined aliases will suffer the same issue when it's
> resolved.

I would be very surprised if that affects Type() to be honest because
that issue is about error message reporting, i.e. "unwinding" to
actual type name a user referenced instead of the actual type.

Best,


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4ier%2BC%2BL5VQXC_CiC%3D9WoipeoTcQQt8oP5kdGaaWBvdQ%40mail.gmail.com.

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

[Paul Jolly]

I think you were unlucky with your choice of type to experiment with.
My understanding is that byte is special cased, despite being an
alias:

https://github.com/golang/go/blob/13e41bcde8c788224f4896503b56d42614e0bf97/src/go/types/universe.go#L25

Consider instead https://play.golang.org/p/MHjgBvbOG__G

On Sat, 22 Aug 2020 at 05:16, 'Dan Kortschak' via golang-nuts
 wrote:
>
> On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote:
> > On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts
> >  wrote:
> > >
> > > I would like to be able to obtain the original type for an alias
> > > given
> > > a source input. I can see in "go/types" that it's possible to know
> > > whether a named type is an alias by `typ.Obj().IsAlias()`, but I
> > > cannot
> > > see how to obtain the actual original type unless it is an alias
> > > for a
> > > basic type.
> > >
> > > Can someone point me to a way to get this information? From the
> > > source
> > > it looks something like
> > > `typ.Obj().Type().(*types.Named).Obj().Type()`.
> > > Is this correct assuming that the original type is a named type?
> >
> > I haven't tested it but I *think* you can just write
> > typ.Underlying().
> >
> > Ian
>
> Thanks, Ian.
>
> No that doesn't work. For example with type byte, you get back the byte
> name.
>
> https://play.golang.org/p/PPjHBotsIsw
>
> Dan
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d3f6c5b7a76f7ea2db93f34fa87917651dcc7ad5.camel%40kortschak.io.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5c%3D5CpNN0uUJp6QJp5dFsSg-wtV_AK4MixTMVmnYY86w%40mail.gmail.com.

Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

[Paul Jolly]

> Why the output of this code is nondeterministic?

See https://golang.org/ref/spec#For_statements, specifically the "For
statements with range clause" subheading, specifically this bullet:

> 3. The iteration order over maps is not specified and is not guaranteed to be 
> the same from one iteration to the next. If a map entry that has not yet been 
> reached is removed during iteration, the corresponding iteration value will 
> not be produced. If a map entry is created during iteration, that entry may 
> be produced during the iteration or may be skipped. The choice may vary for 
> each entry created and from one iteration to the next. If the map is nil, the 
> number of iterations is 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6NkFid3tVxUdy2bC0-2D7kh96Ab66DQcEeVOJEWedhsA%40mail.gmail.com.

Re: [go-nuts] Re: "Unused" transitive module requirements and licenses

[Paul Jolly]

> Suppose a company pulls in the main module into a monorepo. Such a repo might 
> be set up to pull in M1 in its entirety, and thus, recursively, M4 and M5, 
> regardless of whether the main module uses it.

Thanks - that's a useful example.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6X8Xm8jkU3dMv5SZ2kn63-s0DcfWowd8ZE%3DxBJx623Zw%40mail.gmail.com.

[go-nuts] "Unused" transitive module requirements and licenses

[Paul Jolly]

Hi all,

I raised the following question in #tools on Gophers Slack
(https://gophers.slack.com/) but re-raising here for slightly wider
discussion/pointers. It is very related to Bryan Mills' excellent proposal in
https://github.com/golang/go/issues/36460 for lazy module loading.

Q: If my main module requires module M1, but only uses packages within M1 such
that transitive module requirements (of M1) M2 and M3 are used (and not M4 or
M5), what's the situation with respect to the licenses of M4 and M5? By "uses
packages" here I'm considering the output of go list -test -deps on the packages
of the main module.

I had never considered this question until the other day when it dawned on me in
the context of lazy module loading.

Bryan kindly responded with the following:

> I can't give you legal advice, but I can describe the technical aspects.
>
> If your main module is already tidy, then (barring a bug) only the source code
> and go.mod files from M1, M2, and M3 would be read.
>
> When a new dependency needs to be resolved, then the go.mod files — but not
> the source code — for M4 (and perhaps M5) would also be read in order to
> determine what version of the new dependency to add.

Bryan makes a distinction between the go.mod files for M4 and M5 and the source
code in those modules.

Is anyone well-placed to offer some pointers on this question of whether or to
what extent the licenses of M4 and M5 are significant?

Many thanks


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6NyvgZFvWJVJBBna4txwbCjsGoRKXFDV8S2_ER%3D5Chiw%40mail.gmail.com.

Re: [go-nuts] Load function from golang.org/x/tools/go/packages throws "argument list too long" error

[Paul Jolly]

cc golang-tools, bcc golang-nuts

Michael Matloob will be well-placed to advise here.

On Wed, 29 Jan 2020 at 22:12, adam.welc via golang-nuts
 wrote:
>
> I am trying to analyze a large application using Go's static analysis 
> support. I am using the "packages" package to load all application packages 
> using the Load function.  Unfortunately the application is really big and the 
> list of patterns that the Load function takes the second parameter is really 
> long. This causes a problem on Mac OS as in this case it leads to the 
> "argument list too long" error popping up after the Load function is called. 
> The reason for it is that internally, the Load function executes "go list" 
> command passing it the list of patterns as arguments, which leads to 
> exceeding the limit established by Mac OS (which, as far as I can tell, 
> cannot be changed).
>
> The usual workaround for this problem is to split the argument list and apply 
> a given function incrementally to each list fragment - in this case it would 
> mean calling the Load function multiple times with a different subset of the 
> patterns list at each invocation. This, however, does not quite work, as it 
> messes up the SSA representation that I need to generate afterwards using 
> AllPackages function from the "ssautil" package. The AllPackages function 
> constructs a program that contains a "file set" containing all files 
> constituting the program. As far as I can tell, the only way to access this 
> file set during analysis is via the program itself. And this is the gist of 
> the problem, incremental application of the Load function creates a "file 
> set" per increment, and the resulting program during SSA construction will 
> assign only one to the program, making the remaining ones inaccessible during 
> analysis.
>
> I can't think of a viable workaround here (one that I considered is trying to 
> use the loader package but it's deprecated and does not support modules), but 
> perhaps someone will have an advice on how to proceed here...
>
> Adam
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/3dad4625-1b92-4438-b753-c63153c15848%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4tGpyXtuRShujDVQDY_-SRDXMqVaqFnf%3DzbCojUX5Q_w%40mail.gmail.com.

Re: [go-nuts] Re: Advise on working with local modules

[Paul Jolly]

>> Why not just the replace directive in go.mod?
>
> With the replace directive to a local module, the version is ignored and the 
> go tool always use the latest commit.

How are you envisaging that local modules be addressed by commit,
given the target is a directory (where by definition only a single
commit can be "current")?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6_JcPbvwE5RMj2x6YJtsQatCEDA%2BhWL1uHCJpy7SWP2A%40mail.gmail.com.

Re: [go-nuts] Unexpected evaluation order in a return statement with multiple operands

[Paul Jolly]

>   "when evaluating the operands of an expression, assignment, or return 
> statement, all function calls, method calls, and communication operations are 
> evaluated in lexical left-to-right order."

My understanding goes as follows: the operands of the return statement
are i and modify(&i). The comma after "return statement" in the above
sentence is then important: because the only "function calls, method
calls, and communication operations" in that list of operands are (is)
modify(&i).

Hence when i (as in the first operand) is evaluated is not specified.
And therefore it's dangerous to rely on it being one value or another
(which it could be given the example you provide).

There was even some discussion at the London Gophers November 2019
meetup (where the conundrum was very related
https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1)
about whether it would be possible to statically flag potential errors
like this.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%40mail.gmail.com.

Re: [go-nuts] Shell alias to get latest go versions?

[Paul Jolly]

I think you're after something like (for your OS/arch):

wget https://dl.google.com/go/$(curl -s
https://golang.org/dl/?mode=json | jq -r
.[0].version).linux-amd64.tar.gz

The JSON mode of the download page being the key here.

On Tue, 14 Jan 2020 at 09:22, Steve Mynott  wrote:
>
> Does anyone have a simple shell alias, function or similar to get the
> latest released versions of go?
>
> Is there a cleaner way of going this than screen scraping the website
> or looking at tags in git?
>
> --
> Steve Mynott 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CANuZA8R2j8_0pgbNw13qAq82dTJonCsXgnNS0vhKD_dxzwhwfw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5080_QzQiP%3D-gn8E1h7k837FCRr7WQ_D0bBxiyw01QmQ%40mail.gmail.com.

Re: [go-nuts] Existing hermetic end-to-end testing libraries for CLI applications?

[Paul Jolly]

Hi Tom,

> tl;dr Are there any existing end-to-end testing libraries for CLI 
> applications? Specifically, what I'm looking for is a library that makes it 
> easy to test that "running this command should produce this output" without 
> fear that a buggy application could corrupt the filesystem.

I'd suggest looking at:

* https://pkg.go.dev/github.com/rogpeppe/go-internal/testscript?tab=doc
for the CLI testing aspect
* https://pkg.go.dev/mvdan.cc/dockexec?tab=overview for the isolation piece

There are lots of examples of where testscript is being used:
https://github.com/rogpeppe/go-internal/wiki/Users-of-testscript

govim is one such an example where we also provide an example of how
to run those tests via dockexec:

https://github.com/govim/govim/wiki/govim-tests#running-tests---using-cmdgo

In our case it's not so much for isolation, rather providing dependencies.

The #tools channel on slack (or mailing list
https://groups.google.com/forum/#!forum/golang-tools) is also a good
place to chat about this more in case you had any follow-ups.

Best,


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7173qysrk7FrmJFW3FT3hRyKZ0RkvcFE%3DXCrUQPeCLNQ%40mail.gmail.com.

Re: [go-nuts] types lookup for error interface type

[Paul Jolly]

> This seem massively over complicated, so I'm wondering if there is an
> easier way.

I think you're after types.Universe.Lookup("error")?


Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7rrsi9Ai9vhR2GVRRx_dX1w_xjoqGh3davbGbmw5wVkw%40mail.gmail.com.

Re: [go-nuts] querying whether the go command would run in module mode

[Paul Jolly]

I raised https://github.com/golang/go/issues/36052 for discussion.

On Mon, 9 Dec 2019 at 10:29, Dan Kortschak  wrote:
>
> Thanks.
>
> Yes, I always have GO111MODULE=on, hence the difference.
>
> On Mon, 2019-12-09 at 10:04 +, Paul Jolly wrote:
> > > When you're not in a module it returns /dev/null on linux. I don't
> > > suppose this is platform independent?
> >
> > I have to say what you saw surprised me until Daniel Martí and I did
> > a
> > bit of experimentation.
> >
> > It seems the value of GO111MODULE matters here. If you have
> > GO111MODULE=on then the result of go mod env outside of a module
> > context is /dev/null (or your system's equivalent)
> >
> > If you have GO111MODULE unset (i.e. auto) then it is empty string.
> >
> > This is certainly not clear to me from the docs in go help
> > environment.
> >
> > I realise that this way (i.e. with the /dev/null output when
> > GO111MODULE=on) you can distinguish between modules being on/off, as
> > well as whether you're in a module context or not (regardless of
> > whether you have modules on/auto).
> >
> > But this doesn't exactly jump out at you from the docs of go help
> > environment, and I for one have incorrectly advised people on how to
> > check "are you in a module context or not". Because the logic becomes
> > something like:
> >
> > if gomod != "" && gomod != os.DevNull {
> > // we are in a module context
> >
> > I'm going to raise an issue to suggest that the docs are clarified
> > 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7U-TspDFgvqgiFHO2Vu2YUrnHZsz2Pfj-4SY9%3Dv7uevw%40mail.gmail.com.

Re: [go-nuts] querying whether the go command would run in module mode

[Paul Jolly]

> When you're not in a module it returns /dev/null on linux. I don't
> suppose this is platform independent?

I have to say what you saw surprised me until Daniel Martí and I did a
bit of experimentation.

It seems the value of GO111MODULE matters here. If you have
GO111MODULE=on then the result of go mod env outside of a module
context is /dev/null (or your system's equivalent)

If you have GO111MODULE unset (i.e. auto) then it is empty string.

This is certainly not clear to me from the docs in go help environment.

I realise that this way (i.e. with the /dev/null output when
GO111MODULE=on) you can distinguish between modules being on/off, as
well as whether you're in a module context or not (regardless of
whether you have modules on/auto).

But this doesn't exactly jump out at you from the docs of go help
environment, and I for one have incorrectly advised people on how to
check "are you in a module context or not". Because the logic becomes
something like:

if gomod != "" && gomod != os.DevNull {
// we are in a module context

I'm going to raise an issue to suggest that the docs are clarified 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4GP287B7E7nMHnBwZsHUzcNS-4Km_x6GX%3DZvoGbbr2PQ%40mail.gmail.com.

Re: [go-nuts] querying whether the go command would run in module mode

[Paul Jolly]

go env GOMOD - gives the path to the go.mod in use in module mode, and is
empty otherwise (i.e. GOPATH mode)

On Mon, 9 Dec 2019, 00:25 Dan Kortschak,  wrote:

> Is there a way to query whether an invocation of the go command would
> be running in module mode?
>
> thanks
> Dan
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c0c406db898a66fb1fe2638242922512315ff190.camel%40kortschak.io
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7agQLeSYzqGuVX_68gmizpC2Ckd2PMW7i4W_ufc5isiQ%40mail.gmail.com.

Re: [go-nuts] Looking for an app w/ mult. versions of a dependency

[Paul Jolly]

> I'm wondering if any of you other nuts can point out examples?

It's a hypothetical example but perhaps shows enough of what you're after?

https://github.com/go-modules-by-example/index/blob/master/015_semantic_import_versioning/README.md

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4rPdGigqdym5iPsVUQSaOy5hnig6QGiax%3DhZtQ2cL32w%40mail.gmail.com.

Re: [go-nuts] Some questions on using the "golang.org/x/tools/go/packages" package

[Paul Jolly]

AFK but you might also like to post to
https://groups.google.com/forum/#!forum/golang-tools (per
https://github.com/golang/go/wiki/golang-tools)

On Sat, 23 Nov 2019, 15:46 T L,  wrote:

> The packages.Config.ParseFileParseFile docs (
> https://godoc.org/golang.org/x/tools/go/packages#Config) says
>
> // An application may supply a custom implementation of ParseFile
> // to change the effective file contents or the behavior of the parser,
> // or to modify the syntax tree. For example, selectively eliminating
> // unwanted function bodies can significantly accelerate type checking.
>
>
> But how to exactly do to avoid parsing function bodies? And how to set the
> go/types.Config.IgnoreFuncBodies
> to false when calling packages.Load() to avoid checking function bodies? I
> failed to find the option to set it.
>
>
> The packages.Config.Tests docs says
>
> // If Tests is set, the loader includes not just the packages
> // matching a particular pattern but also any related test packages,
> // including test-only variants of the package and the test executable.
> //
> // For example, when using the go command, loading "fmt" with Tests=true
> // returns four packages, with IDs "fmt" (the standard package),
> // "fmt [fmt.test]" (the package as compiled for the test),
> // "fmt_test" (the test functions from source files in package fmt_test),
> // and "fmt.test" (the test binary).
>
>
> What do the "the package as compiled for the test" and "the test binary"
> mean?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f4116dc3-9c45-4a28-85d9-d4690e5c1eea%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6kWr-Czo1Sgep-jv0DUy1bUXsheHRFA-PW1euKpYx6TQ%40mail.gmail.com.

Re: [go-nuts] Enforce immutability through static analysis

[Paul Jolly]

May or may not be of interest, but I experimented with an alternative
approach in 
https://github.com/myitcv/x/blob/master/immutable/_doc/immutableGen.md

Although this is where the term "immutable" gets massively overloaded,
because the result of immutableGen is (as I understand it) persistent
data structures. My use of the term "immutable" is more a nod to
https://github.com/immutable-js/immutable-js which inspired the
pattern.

That caveat aside.

It's a code generation approach whereby you declare immutable templates, e.g.

type _Imm_Banana struct {
   Name string
   age  int
}

You then get code generated get/set methods that respect the
exported-ness of the template fields.

immutableVet can then be used to verify correct use of struct fields
within a package, i.e. that you don't have any non-generated code that
subverts the get/set methods.

You can also have "immutable" maps and slices.



On Thu, 21 Nov 2019 at 16:16,  wrote:
>
> Dear Gophers!
>
> I was wonder if it possible to force immutability on the method receiver? I 
> know Go doesn't support immutable types and that it is possible to pass the 
> receiver by value but if the receiver struct has a field with a pointer type 
> the method may still manipulate it:
>
> type Counter struct {
>  n *int
> }
>
> func (c Counter) Render() string {
>  *c.n += 1
>  return strconv.Itoa(*c.n)
> }
>
> I would like to force (or hint) the the user in writing interface{ Render() 
> string } implementations that don't manipulate the method receiver. So that 
> they can be considered 'pure' in the functional sense of the word and can be 
> called repeatedly without side effects. I would like the user to be able to 
> define implementations of interface{ Render() string }such that I can safely 
> call the method and use the returned string to write a http.Reponse without 
> it changing between requests.
>
> I control the way in which Render is called and I am open to crazy answers 
> such as:
>
> - Maybe it is possible to use reflect to "switch" out the value receiver for 
> a temporary value which is discarded after every call?
> - Maybe i can use static code analysis to warn the user? How feasible is it 
> to prevent all cases of this happening with just static code analysis? can 
> this be done at runtime?
> - I could instead ask the user to provide a factory function that init new 
> Counters but maybe very inefficient if the structs are very large (or have 
> many nested structs)?
>
> Or maybe there is some possibility that I'm missing?
>
> Cheers,
>
> Ad
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7ee35405-fef4-415b-ae5d-95322b4065aa%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4x%2Bx4k8rQhoLVbNHeBB_-r9zAMYpXDZYhU%3DSamVEmuFg%40mail.gmail.com.

Re: [go-nuts] Parsing go.mod

[Paul Jolly]

> Sorry I left out the details. So far it's two specific properties I need for 
> instructions in my build process:
>
> 1) The full name of the package

go list -f {{.Name}} example.com/blah

> 2) The version of the protobuf dependency for locking the right version 
> protoc-gen-go before running protoc (that has been asked quite a few times, 
> total hack, but works).

go list -f {{.Version}} -m example.com/blah

Note that if you have a replace directive for example.com/blah then
the replace target might have a version.

For more detail on either of the above see:

go help list

>
> Best,
> James
>
> On Monday, September 2, 2019 at 10:58:53 PM UTC-7, Kurtis Rader wrote:
>>
>> On Mon, Sep 2, 2019 at 10:44 PM James Pettyjohn  wrote:
>>>
>>> This might be a bad idea but I'm trying to parse the go.mod file for data 
>>> as part of my build process - if at all possible I'd like to avoid 
>>> duplicating the data that is already there in another file.
>>
>>
>> In this type of situation you should explain why you need to parse a go.mod 
>> file. Especially since you seem to be asking something not already asked a 
>> thousand times. It is possible, perhaps likely, the reason you want to do 
>> this can be solved some other way.
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/8b716cac-0eb6-4e95-bdde-12ee832e06a4%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4MouSb-spFS-NvdYZdC827%2Bx28pXLD0ABd%3D52AHBvfaw%40mail.gmail.com.

Re: [go-nuts] Parsing go.mod

[Paul Jolly]

Also note that you can run:

go mod edit -json

and get JSON output.

go help mod edit

will given you the types you can then use to unmarshal the JSON.

Failing that, the code that Dan referenced has been factored out into:

https://godoc.org/github.com/rogpeppe/go-internal/modfile

On Tue, 3 Sep 2019 at 08:21, James Pettyjohn  wrote:
>
> Thanks. I saw the same being done by vgo - might be viable.
>
> On Monday, September 2, 2019 at 10:52:45 PM UTC-7, kortschak wrote:
>>
>> Not really exposed, but there is code you could copy.
>>
>> https://golang.org/pkg/cmd/go/internal/modfile/#Parse
>>
>> On Mon, 2019-09-02 at 22:44 -0700, James Pettyjohn wrote:
>> > Hi,
>> >
>> > This might be a bad idea but I'm trying to parse the go.mod file for
>> > data
>> > as part of my build process - if at all possible I'd like to avoid
>> > duplicating the data that is already there in another file.
>> >
>> > Is there an exposed package that can be used for this?
>> >
>> > - J
>> >
>>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7a06f505-187e-473f-b748-a8bf7f114bf6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5xz0Hjew_RuJHTeah%3DyJVr56sS55ym6rDaFfABBFAOAA%40mail.gmail.com.

Re: [go-nuts] Re: how to create path/v2 and path/v3 and path/v4 in same repo

[Paul Jolly]

The short version is:

* semantic version git tags are the means of releasing new versions
* you can follow whatever strategy you like when it comes to
maintaining multiple major versions of a module (you might not need
to); branch, subdirectory... Just so long as the git tag gets you to
the right commit
* major versions N>=2 which do not resolve to a module which has /vN
at the end of the module path will be required as +incompatible

On Wed, 28 Aug 2019 at 03:40, Jason E. Aten  wrote:
>
> Thanks guys.
>
> https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
>
> seems to say that the answer is yes, but that it won't be backwards 
> compatible with tags and go.mod alone.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/1801b795-ff54-425a-abc4-7ec28b0f679e%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7q8Np-v6Vb16Vo3Hg6%2BGQk43HAv0y-YROcvSTM4QAUgA%40mail.gmail.com.

Re: [go-nuts] Re: how to create path/v2 and path/v3 and path/v4 in same repo

[Paul Jolly]

To add to Chris' response also see the wiki
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Also see https://github.com/golang/go/issues/33637 for details on how
modules documentation will be getting a revamp in 1.14.

On Tue, 27 Aug 2019 at 12:49, Chris Hines  wrote:
>
> You might be able to find an answer to your question in this article: 
> https://github.com/go-modules-by-example/index/tree/master/016_major_version_repo_strategy
>
> On Tuesday, August 27, 2019 at 6:31:57 AM UTC-4, Jason E. Aten wrote:
>>
>> With an eye towards implementing semantic import path versioning, is it 
>> possible to have
>>
>> https://gihtub.com/me/path/v2
>> https://github.com/me/path/v3
>>
>> point (somehow, the question is how?) to different tags within the same 
>> https://github.com/me/path  repo?
>>
>> Thanks!
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/3f0902ba-3f19-4b74-99a0-969d14dc6bc7%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6VjjjWuzAoSHqP4HWoDENYcebW8yGyJJyR4UoxCuoFvg%40mail.gmail.com.

Re: [go-nuts] Open Source audit of go package dependencies for security vulnerabilities?

[Paul Jolly]

Some related discussion in https://github.com/golang/go/issues/24031 and
linked issues.

On Tue, 13 Aug 2019 at 10:32, Steve Mynott  wrote:

> I've been introduced to https://rubysec.com/ which has a database
> which easily integrates with builds to check for known security
> vulnerabilities in third party libraries and was wondering whether
> anything similar exists for go packages?
>
> A quick search finds https://snyk.io/vuln?type=golang which appears
> similar but is basically a pay service based on node.js.
>
> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project
> looks interesting but doesn't include go.
>
> Does such an open source version exist for go which is written in go
> and integrates easily with builds?
>
> --
> Steve Mynott 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANuZA8RhYQrLY%3DJ_BgqYzJm%3Dehyr%3DbCo1F%3D2pCcJJ8cf2u-Vig%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4cAa-t%2B12C0br2tMo0fef0fs%3D4rSnikVkuGrWsxQ-V3g%40mail.gmail.com.

Re: [go-nuts] Replace modules from command line

[Paul Jolly]

You won't be able to avoid editing the go.mod - it's the starting point for
all module resolution.

How about taking a copy of the original go.{mod,sum} and restoring them, or
using git checkout . to trash unstaged changes?

On Tue, 6 Aug 2019, 07:26 Peter Feichtinger,  wrote:

> Thanks for that, this will come in handy for editing the go.mod file.
> But I'd like to avoid editing the file at all.
>
>
> On Monday, August 5, 2019 at 7:16:08 PM UTC+2, Paul Jolly wrote:
>>
>> Take a look at go mod edit
>>
>> https://golang.org/cmd/go/#hdr-Module_maintenance
>>
>>
>>
>> On Mon, 5 Aug 2019, 18:45 Peter Feichtinger,  wrote:
>>
>>> Hi Go Nuts,
>>>
>>> I have a rather unusual use case and I'm hoping for some input.
>>>
>>> For testing purposes, I want to build a Go binary with different
>>> versions of one of its dependencies. The only way I could think of was to
>>> modify the go.mod file to add a replace directive with the version I
>>> want to test.
>>> Instead I'd like to avoid having to modify the go.mod file during the
>>> build and specify the replacement on the command line instead, but I don't
>>> think that's possible.
>>>
>>> Do you guys have any ideas on how else I might accomplish overriding a
>>> module version during build?
>>>
>>> -- Peter
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/efc91729-47a6-4dcb-a08d-6c907b24bd56%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/efc91729-47a6-4dcb-a08d-6c907b24bd56%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6ced2780-eca5-4692-a7f6-c0c73ad5b966%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/6ced2780-eca5-4692-a7f6-c0c73ad5b966%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7ELJawV7SVzba%3DZNrwSC7QXfekB-VDC6yPf-3TOyubLA%40mail.gmail.com.

Re: [go-nuts] Replace modules from command line

[Paul Jolly]

Take a look at go mod edit

https://golang.org/cmd/go/#hdr-Module_maintenance



On Mon, 5 Aug 2019, 18:45 Peter Feichtinger,  wrote:

> Hi Go Nuts,
>
> I have a rather unusual use case and I'm hoping for some input.
>
> For testing purposes, I want to build a Go binary with different versions
> of one of its dependencies. The only way I could think of was to modify the
> go.mod file to add a replace directive with the version I want to test.
> Instead I'd like to avoid having to modify the go.mod file during the
> build and specify the replacement on the command line instead, but I don't
> think that's possible.
>
> Do you guys have any ideas on how else I might accomplish overriding a
> module version during build?
>
> -- Peter
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/efc91729-47a6-4dcb-a08d-6c907b24bd56%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5Hk9rG7%3DvzmH6voFuGxBH0W_BCDT9uwwZ2OHkpeVC%3D%2Bg%40mail.gmail.com.

Re: [go-nuts] Generating LSP protocol Go types

[Paul Jolly]

Just to add to Peter's response.

The issue tracking making these packages non-internal is
https://github.com/golang/go/issues/31080

FWIW, a number of people (myself included) simply clone the internal
packages for our own purposes. Here are those packages cloned, with
import paths changed:

https://github.com/myitcv/govim/tree/master/cmd/govim/internal

And here is the hacky script I used to clone those packages:

https://github.com/myitcv/govim/blob/master/_scripts/revendorToolsInternal.sh

Also, you may be interested in golang tools
(https://github.com/golang/go/wiki/golang-tools). There is a good
amount of discussion about this sort of thing in those various
channels


Paul

On Sat, 13 Jul 2019 at 16:05, 'Peter Weinberger (温博格)' via golang-nuts
 wrote:
>
> I'm responsible for some of that code but other than that, I'm just giving my 
> personal opinion.  There's no fundamental reason it couldn't be public, but,
> 1. They change all the time (weekly for some of it, more slowly for 
> tsprotocol.go, which follows the Microsoft code)
> 2. They are adapted to the repository's version of gopls, and changes in 
> gopls cause changes in these files.
>
> One way to try things out is to clone the repository, and then in master, add 
> your own git project. It has access to the internal files, but you'd push and 
> pull it independently. That doesn't solve your problem, but maybe it delays 
> it.
>
> On Sat, Jul 13, 2019 at 7:43 AM  wrote:
>>
>> Hi there,
>>
>> I am trying to write a Go client for gopls.  Ideally I would like to be able 
>> to to import a package that defines Go types for all the messages that can 
>> be sent to / received from the server, which is something that obviously the 
>> gopls server also has to do.  Unfortunately the protocol files are not in a 
>> public package 
>> (https://github.com/golang/tools/tree/master/internal/lsp/protocol). There 
>> are instructions to generate the Go files at 
>> https://github.com/golang/tools/blob/master/internal/lsp/protocol/typescript/README.md
>>  but they require some files from that repository so that is not very useful.
>>
>> Would it make sense for this to be extracted as a public package?  If so, 
>> how would I go about achieving this?  If not, what would be a sensible 
>> approach for me?
>>
>> Regards,
>>
>> Arnaud Delobelle
>>
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/8fdc691a-345a-4162-a6cf-2e9b5cb078ec%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOUkXSqVC07hpiPty3Yvi3g79itOWfg%2Br2Oz96NztDA10%2BLbTA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn7uCcjGN8x3vOtDwDgp5VZoJQ6mj3fy%2BYW5EBXHnrZcEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[Paul Jolly]

Just to expand on Russ' point about golang-tools:
 

> In fact there is now a roughly biweekly “Go tools” meeting which is 
> typically attended by more tool and editor integration authors from outside 
> Google than from inside Google and organized by a contributor outside 
> Google. (If you want to know more about that, email Paul Jolly, 
> pa...@myitcv.io .)
>

More details available in the golang-tools wiki: 
https://github.com/golang/go/wiki/golang-tools, including links to YouTube 
recordings and notes from previous sessions. 

Our standards have slipped somewhat and we now meet on Hangouts once a 
month, but that somewhat belies the huge progress currently being made with 
gopls, go/packages, go/analysis and all the various editors integrations. 

The (now) monthly calls, mailing list and Slack channels are open to 
everyone.

Please feel free to email me (p...@myitcv.io) or join 
https://groups.google.com/forum/#!forum/golang-tools if you have any 
questions.

Thanks


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/beefdd05-b5b9-41cc-881e-878f2e8325d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] a way to query the module sum of a dependency with the go tool?

[Paul Jolly]

FWIW, none that I'm aware of. If there were to be such a command I
would probably expect it be an option to go mod verify.

Is there a problem with using go.sum in the way you're proposing?

Or is this more a convenience thing?

On Thu, 21 Mar 2019 at 22:03, Dan Kortschak  wrote:
>
> Is there a command that does something like `go list -m ` but
> also outputs the sum for the module and module's go.mod? Other than
> `grep  go.sum`.
>
> thanks
> Dan
>
> --
> 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 command support for "make"

[Paul Jolly]

Hi Ian,

> test $(go list -f '{{.Stale}}' internal/package$) = "true"

Does .Stale still have meaning/is it still accurate in a build cache world?

-- 
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] nested modules in a single repo

[Paul Jolly]

Modules can contains multiple packages
(https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more).

So all the packages listed in the tree above can be contained within a
single module (go.mod) defined at the top most level.

To take a random example of this, take a look at
https://github.com/rogpeppe/go-internal. The module
github.com/rogpeppe/go-internal contains multiple packages:

github.com/rogpeppe/go-internal/cache
github.com/rogpeppe/go-internal/cmd/testscript
github.com/rogpeppe/go-internal/cmd/txtar-addmod
github.com/rogpeppe/go-internal/cmd/txtar-goproxy
github.com/rogpeppe/go-internal/cmd/txtar-savedir
...

The tags for releases using this top-level approach are then simple:

https://github.com/rogpeppe/go-internal/tags

As covered in the Background
(https://github.com/go-modules-by-example/index/blob/master/009_submodules/README.md#background)
it's highly likely this setup will suit all your needs, but please ask
back here in case you come across a situation that you think is not
covered.

On Sat, 9 Mar 2019 at 08:42, Abhishek Sudhakaran  wrote:
>
> not required, the service must be able to import bll/* and possibly other sub 
> packages.
>
> On Saturday, March 9, 2019 at 2:31:48 AM UTC+5:30, Paul Jolly wrote:
>>
>> (full disclosure, I wrote
>> https://github.com/go-modules-by-example/index/blob/master/009_submodules/README.md)
>>
>> Quick first question: are you absolutely sure you need multiple modules?
>>
>> https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
>>
>> On Fri, 8 Mar 2019 at 20:49, Abhishek Sudhakaran  wrote:
>> >
>> > Trying to make modules work for the below project structure
>> >
>> > .
>> > ├── bll
>> > │   ├── billing
>> > │   │   ├── details.go
>> > │   │   └── go.mod
>> > │   ├── complaint
>> > │   │   ├── details.go
>> > │   │   └── go.mod
>> > │   └── task
>> > │   ├── details.go
>> > │   └── go.mod
>> > ├── go.mod
>> > └── services
>> > ├── billing
>> > │   ├── go.mod
>> > │   └── main.go
>> > ├── complaint
>> > │   ├── go.mod
>> > │   └── main.go
>> > └── task
>> > ├── go.mod
>> > └── main.go
>> >
>> >
>> > Already tried solutions for a similar question :
>> >
>> > https://github.com/go-modules-by-example/index/tree/master/009_submodules
>> > https://roberto.selbach.ca/intro-to-go-modules/
>> >
>> > if the modues are nested as above, how does the git tag(s) change ??? 
>> > tried bll/task/v0.1.1 and task/v0.1.1 etc. did not work.
>> >
>> > error is like:
>> >
>> > cannot find module providing package github.com/{name}/{repo}/bll/task
>> >
>> > should bll/go.mod services/go.mod be there ? (tried that also , didn't 
>> > work)
>> >
>> > I have seen examples for single level directories, but not for nested ones.
>> >
>> > Can you please point out what I am missing ?
>> >
>> > Thanks.
>> >
>> > --
>> > 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] nested modules in a single repo

[Paul Jolly]

(full disclosure, I wrote
https://github.com/go-modules-by-example/index/blob/master/009_submodules/README.md)

Quick first question: are you absolutely sure you need multiple modules?

https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories

On Fri, 8 Mar 2019 at 20:49, Abhishek Sudhakaran  wrote:
>
> Trying to make modules work for the below project structure
>
> .
> ├── bll
> │   ├── billing
> │   │   ├── details.go
> │   │   └── go.mod
> │   ├── complaint
> │   │   ├── details.go
> │   │   └── go.mod
> │   └── task
> │   ├── details.go
> │   └── go.mod
> ├── go.mod
> └── services
> ├── billing
> │   ├── go.mod
> │   └── main.go
> ├── complaint
> │   ├── go.mod
> │   └── main.go
> └── task
> ├── go.mod
> └── main.go
>
>
> Already tried solutions for a similar question :
>
> https://github.com/go-modules-by-example/index/tree/master/009_submodules
> https://roberto.selbach.ca/intro-to-go-modules/
>
> if the modues are nested as above, how does the git tag(s) change ??? tried 
> bll/task/v0.1.1 and task/v0.1.1 etc. did not work.
>
> error is like:
>
> cannot find module providing package github.com/{name}/{repo}/bll/task
>
> should bll/go.mod services/go.mod be there ? (tried that also , didn't work)
>
> I have seen examples for single level directories, but not for nested ones.
>
> Can you please point out what I am missing ?
>
> Thanks.
>
> --
> 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] Re: WebAssembly: Auto-generating Go bindings for javascript/DOM from the Web Standards.

[Paul Jolly]

>
> I have started to work on DOM binding based on WebIDL and a binding
> generator. I don't have full WebIDL support yet, but it does process idl
> from about 80 specifications. See https://gowebapi.github.io for more
> details.
>

Hi Martin,

I'd like to second Tyler's suggestion that you start a new thread, very
exciting!

My question is: to what extent is your WebIDL parser and AST equivalent
separate from the Go-WASM target code you are generating?

Reason being, I'd like the use the IDL specs to generate Go code for React
bindings, replacing currently hand-written code. This will likely require
some sort of tweaks/annotations atop WebIDL for any React vagaries, hence
I'm wondering to what extent the WebIDL interface is reusable.

Thanks,


Paul

-- 
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: get Package from types.Type

[Paul Jolly]

Underlying is the identity function for all types except *types.Named
(https://github.com/golang/example/tree/master/gotypes#named-types),
so this won't get you what you want.

Instead what I think you're after is type asserting against the
types.Type you have
(https://github.com/golang/example/tree/master/gotypes#types):

Type = *Basic
 | *Pointer
 | *Array
 | *Slice
 | *Map
 | *Chan
 | *Struct
 | *Tuple
 | *Signature
 | *Named
 | *Interface

Then walking "inside" the respective type as required. For example,
you'll probably want to dereference a *types.Pointer via Elem(),
similarly for a slice. For a map you potentially have a more complex
decision with two types!


Paul

On Sat, 16 Feb 2019 at 08:55, Randall O'Reilly  wrote:
>
> nevermind - I think I figured it out — just need to drill down Underlying 
> until you find types.Named and get the Obj().Pkg() from that.  Only Named 
> types have a package home..
>
> - Randy
>
> > On Feb 16, 2019, at 12:51 AM, Randall O'Reilly  wrote:
> >
> > I’m probably missing something very basic, but I have a go/types.Type and I 
> > want to find which package it was defined in.  I can get the path of the 
> > Package using TypeString but somehow I can’t seem to figure out how to get 
> > the *Package itself!  I can’t find a “lookup package by path” and 
> > LookupParent or my own attempt to crawl the Scope() hierarchy up and down 
> > doesn’t seem to be working.. Thanks,
> >
> > - Randy
> >
>
> --
> 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 install touches the result file even if no changes

[Paul Jolly]

Tim - in case it's of any interest, I am in the process of (re)writing
a dependency-aware wrapper around go generate that caches results in
an artefact cache (i.e. only re-runs code generation as required).

On Sat, 26 Jan 2019 at 03:56, 'Tim Hockin' via golang-nuts
 wrote:
>
> Fair point, of course.
>
> I care because Kubernetes and it's family of projects have Makefiles to 
> encapsulate trickier aspects of building, including code generation.  
> Compiling kubernetes takes a LONG time.  It would be nice to avoid 
> re-triggering secondary actions when the primary artifacts have not changed.
>
> Could I checksum?  Sure, but then I am writing a custom builder, so I might 
> as well use Bazel (which has other issues).
>
> It's not a huge deal, today, but I really wanted to understand it.  It just 
> seemed broken.
>
> On Fri, Jan 25, 2019, 5:41 PM Ian Lance Taylor  wrote:
>>
>> On Fri, Jan 25, 2019 at 3:51 PM Tim Hockin  wrote:
>> >
>> > I don't grok that reasoning - can you expand on it?  Assume for a
>> > second that it did NOT update mtime if the result did not change.  I
>> > can be confident that same mtime == no change, right?  It doesn't
>> > imply that different mtime == something change, but I think that's OK
>> > (for my use, maybe I am limited in my imagination). Even
>> >
>> > Does it really matter if some corner cases result in spurious updates?
>>
>> It would be nice if it worked that way, but I'm confident that if we
>> avoided updating mtime when we knew the file did not change, and then
>> later started updating mtime again, people would file bugs saying that
>> the mtime was updated incorrectly.  Right now we provide a simple API:
>> run "go build" or "go install" and your executable will be up to date.
>> Why do we need a more complex API?
>>
>> Let me turn it around: why do you care?  For cases where you do care,
>> could you instead keep a hash of the file contents?  For what it's
>> worth, you can fetch a hash of a Go program by running "go tool
>> buildid PROGRAM".  See https://golang.org/cmd/buildid.
>>
>> Ian
>>
>>
>>
>> > On Fri, Jan 25, 2019 at 3:02 PM Ian Lance Taylor  wrote:
>> > >
>> > > On Fri, Jan 25, 2019 at 1:07 PM 'Tim Hockin' via golang-nuts
>> > >  wrote:
>> > > >
>> > > > Example:
>> > > >
>> > > > ```
>> > > > $ which git-sync
>> > > >
>> > > > $ go install -installsuffix "static" ./cmd/git-sync/
>> > > >
>> > > > $ ls -l --full-time `which git-sync`; md5sum `which git-sync`
>> > > > -rwxr-xr-x 1 thockin primarygroup 13956902 2019-01-25
>> > > > 13:04:40.758632955 -0800
>> > > > /usr/local/google/home/thockin/src/go/bin/git-sync
>> > > > 1200f479c8ba86f70f0e4a885ecdd5f2
>> > > > /usr/local/google/home/thockin/src/go/bin/git-sync
>> > > >
>> > > > $ go install -installsuffix "static" ./cmd/git-sync/
>> > > >
>> > > > $ ls -l --full-time `which git-sync`; md5sum `which git-sync`
>> > > > -rwxr-xr-x 1 thockin primarygroup 13956902 2019-01-25
>> > > > 13:04:53.817700697 -0800
>> > > > /usr/local/google/home/thockin/src/go/bin/git-sync
>> > > > 1200f479c8ba86f70f0e4a885ecdd5f2
>> > > > /usr/local/google/home/thockin/src/go/bin/git-sync
>> > > > ```
>> > > >
>> > > > Is the desired behavior or just a side-effect?  Is there any way to
>> > > > defeat it?  Would a patch for this be shot down?
>> > >
>> > > This is intended behavior.  The comment in the code
>> > > (https://golang.org/src/cmd/go/internal/work/exec.go) is
>> > >
>> > > // Whether we're smart enough to avoid a complete rebuild
>> > > // depends on exactly what the staleness and rebuild algorithms
>> > > // are, as well as potentially the state of the Go build cache.
>> > > // We don't really want users to be able to infer (or worse start 
>> > > depending on)
>> > > // those details from whether the modification time changes during
>> > > // "go install", so do a best-effort update of the file times to make it
>> > > // look like we rewrote a.Target even if we did not. Updating the mtime
>> > > // may also help other mtime-based systems that depend on our
>> > > // previous mtime updates that happened more often.
>> > > // This is still not perfect - we ignore the error result, and if the 
>> > > file was
>> > > // unwritable for some reason then pretending to have written it is also
>> > > // confusing - but it's probably better than not doing the mtime update.
>> > > //
>> > > // But don't do that for the special case where building an executable
>> > > // with -linkshared implicitly installs all its dependent libraries.
>> > > // We want to hide that awful detail as much as possible, so don't
>> > > // advertise it by touching the mtimes (usually the libraries are up
>> > > // to date).
>> > >
>> > > 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.

-- 
You re

Re: [go-nuts] What exactly is a method set?

[Paul Jolly]

Have you see the Go Spec?

https://golang.org/ref/spec#Method_sets

On Sun, 20 Jan 2019 at 12:37, 伊藤和也  wrote:
>
> What exactly is a method set?
>
> --
> 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] multiple binaries from a single directory with go modules?

[Paul Jolly]

Perhaps the most idiomatic way of achieving this is:

GOBIN=$PWD go install ./cmd/{foo,bar}

go install is also more efficient than go build because it will only
perform the link step if the target is out of date.

I'm no expert with make, so I don't know how this sort of approach
maps back onto make.

Returning however to the problem you're seeing with your existing
setup, a change in Go 1.12 should prevent the race condition you're
seeing:

https://go-review.googlesource.com/c/go/+/146380

On Fri, 18 Jan 2019 at 01:41, Tycho Andersen  wrote:
>
> Hi everyone,
>
> I'm trying to get an existing project which outputs multiple binaries
> to work with go modules. The package follows roughly the recommended
> layout: https://github.com/golang-standards/project-layout
>
> That is, it looks like
>
> /go.mod
> /go.sum
> /code.go
> /cmd/foo/main.go
> /cmd/bar/main.go
>
> I have a top level make file that looks roughly like:
>
> all: foo bar
>
> foo: ...
> go build -o foo ./cmd/foo/...
>
> bar: ...
> go build -o bar ./cmd/bar/...
>
> When I type "make", it seems like go.sum and go.mod end up with only
> bar's dependencies, because the last go invocation prunes the "unused"
> dependencies from the module files. I've tried various ways of using
> mutiple go.mod and go.sum files (one in each binary directory), but I
> can't quite get the includes of the top level package right.
>
> I see https://github.com/golang/go/issues/14295, which will solve this
> problem for me, but it doesn't exist yet.
>
> Is there some clever way of structuring a project like this with go
> modules that I haven't figured out yet?
>
> Thanks,
>
> Tycho
>
> --
> 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] Will golang.org/x/sys be getting a go.mod file?

[Paul Jolly]

See https://github.com/golang/go/issues/27858 and related issues.

On Fri, 11 Jan 2019 at 13:49,  wrote:
>
> Hello guys,
>
> Apologies if this has already been discussed but I couldn't find it.
>
> I've just converted a server to use modules. I did it by "go mod init 
> example.com/server-name" in the directory where "package main" is. I then got 
> the latest module for each dependency by doing "go get -u". The resulting 
> dependency list showed me which packages are not yet Go module enabled, and 
> where I have work to do:
>
> module example.com/server-name
>
> require (
> github.com/coreos/bbolt v1.3.0 // indirect
> github.com/daviddengcn/go-colortext v0.0.0-20180409174941-186a3d44e920 // 
> indirect
> golang.org/x/sys v0.0.0-20190109145017-48ac38b7c8cb // indirect
> )
>
> So, I see that I've got some work to do to request that go-colortext converts 
> to a Go module, or at least makes a semver tag.
>
> And also, it made me come here to search for how/when to expect 
> golang.org/x/sys to act like a real module.
>
> Thanks for any pointers to an explanation of the Go team's plans for 
> golang.org/x packages.
>
>   -jeff
>
> --
> 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] Re: WebAssembly: Auto-generating Go bindings for javascript/DOM from the Web Standards.

[Paul Jolly]

Yes; see https://github.com/golang/go/wiki#the-go-community for
details on how to join.

On Tue, 1 Jan 2019 at 19:49, Chris FractalBach  wrote:
>
> Are the # channels on slack?
>
> --
> 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 Modules should detect breaking changes on public API (exported members) end enforce semver

[Paul Jolly]

Oh, and 
https://github.com/go-modules-by-example/index/blob/master/019_apidiff/README.md
for a quick demo on apidiff.

On Wed, 19 Dec 2018 at 19:10, Paul Jolly  wrote:
>
> Please see:
>
> * https://github.com/golang/go/issues/26420
> * https://godoc.org/golang.org/x/exp/cmd/apidiff which uses
> https://godoc.org/golang.org/x/exp/apidiff
>
> Effectively what you are discussing is broadly covered, at least based
> on current thinking, in the go release command.
>
> On Wed, 19 Dec 2018 at 18:51, Geovani de Souza  
> wrote:
> >
> > First, let me say that the current implementation of Go Modules is awesome 
> > and solves most of the problems I've faced until now.
> >
> > In the spirit of embracing good packages and stability for consumers, I 
> > think that the current tooling should detect breaking changes and enforce 
> > (or at least, recommend) upgrade in the semver of those packages.
> >
> > By breaking change, I mean:
> >
> > - If we add a new type or func on an existing type (a new feature), it's 
> > not considered a breaking change;
> > - If we change the signature of an existing method or remove some 
> > type/func, it's considered a breaking change;
> >
> > Of course, we can break existing packages by changing it's implementation, 
> > but I'm talking about public API, only.
> >
> > I'm not sure how to implement this, but I find this paper 
> > (https://homepages.dcc.ufmg.br/~mtov/pub/2018-saner-apidiff.pdf) and 
> > recommend looking forward how Elm achieve that.
> >
> > ---
> >
> > What do you think about it?
> >
> > --
> > 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 Modules should detect breaking changes on public API (exported members) end enforce semver

[Paul Jolly]

Please see:

* https://github.com/golang/go/issues/26420
* https://godoc.org/golang.org/x/exp/cmd/apidiff which uses
https://godoc.org/golang.org/x/exp/apidiff

Effectively what you are discussing is broadly covered, at least based
on current thinking, in the go release command.

On Wed, 19 Dec 2018 at 18:51, Geovani de Souza  wrote:
>
> First, let me say that the current implementation of Go Modules is awesome 
> and solves most of the problems I've faced until now.
>
> In the spirit of embracing good packages and stability for consumers, I think 
> that the current tooling should detect breaking changes and enforce (or at 
> least, recommend) upgrade in the semver of those packages.
>
> By breaking change, I mean:
>
> - If we add a new type or func on an existing type (a new feature), it's not 
> considered a breaking change;
> - If we change the signature of an existing method or remove some type/func, 
> it's considered a breaking change;
>
> Of course, we can break existing packages by changing it's implementation, 
> but I'm talking about public API, only.
>
> I'm not sure how to implement this, but I find this paper 
> (https://homepages.dcc.ufmg.br/~mtov/pub/2018-saner-apidiff.pdf) and 
> recommend looking forward how Elm achieve that.
>
> ---
>
> What do you think about it?
>
> --
> 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] Versioning golang.org/x/foo packages

[Paul Jolly]

Just to briefly note the discussion in
https://github.com/golang/go/issues/27858 (and other issues linked
within that one).
On Fri, 14 Dec 2018 at 15:00, David Riley  wrote:
>
> Hi all,
>
> We're building with go 1.10.x and dep for a project at work, and having been 
> bitten twice in the space of a week with unversioned upstream executables 
> fetched via "go get" causing strife with versioned vendor code fetched by 
> "dep", we've been working on making our build environment hermetic (we'll be 
> moving to modules soon when we move to 1.11, especially because we use 
> Artifactory, which supports vgo registries so we can protect our build chain, 
> but for now we're stuck with dep).
>
> Our common solution for this is to make sure the tool is put in the 
> "required" stanza in Gopkg.toml, then running "dep ensure" to make sure it 
> ends up in the Gopkg.lock file so the Docker build can pick it up when it 
> runs "dep ensure --vendor-only". This works pretty well for protoc-gen-go 
> from protobuf and mockgen (the two tools that broke our build this past 
> week), but I also want to do the same for goyacc, which lives in 
> golang.org/x/tools.
>
> I notice that nothing from the golang.org repository is at all versioned, so 
> as far as I can tell, it all comes from the master branch.  How do I version 
> these to ensure that they don't break with older/other Go versions?  Is there 
> some sort of guarantee that they'll work at least n revisions back?  I'm 
> already extremely skeptical about the practice of just fetching all packages 
> from git repositories, given how easy it is to slip malicious code in that 
> way, so requiring a "go get" for those tools doesn't exactly give me the warm 
> and fuzzies.
>
>
> - 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.

-- 
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] Rethink possibility to make circular imports

[Paul Jolly]

Can I suggest you provide a real example to help motivate why you
think circular package imports should work, and therefore what they
would solve?

I will note that circular module dependencies are possible and have
good reasons to exist
(https://github.com/go-modules-by-example/index/blob/master/013_cyclic/README.md)
On Thu, 29 Nov 2018 at 13:22, Michel Levieux  wrote:
>
> The last few days I've been thinking a lot about the fact that Go does not 
> allow circular imports.
> I'm not really sure of why it currently works that way, but from what I've 
> understood the way the compiler works - which is also the reason why 
> compilation of Go programs is much faster than other languages - makes it 
> quite difficult to authorize circular imports.
>
> I'm a young developer (not particularly in Go, I have only 2-3 years of 
> experience at total) so I'm looking forward to hearing your opinion guys, but 
> I think Go2 should allow importing packages circularly. I have no practical 
> reason to think that, except I've been tricking many times to have a 
> structure in my project with which I can at least build.
>
> The main reason why I'm strongly convinced forbidding circular imports is not 
> a good thing is that it separates too much the problem space from the 
> solution space. In Golang, the majority of the solutions we find are just the 
> translation of the logic behind our head into a language a computer can 
> understand - I emphasize this because it might not be true for all languages 
> (take Prolog for instance). Most of the time when you read a well written 
> program, you clearly get the underlying logic that led to this particular 
> solution, AND implementation of the solution.
>
> BUT - I think that there are some cases (and not just a few) when from a 
> logical point of view, the solution is clear, and we have to take the 
> structure of a project away from that logic, because circular imports are not 
> permitted. The human brain works in such a manner that circular imports make 
> sense, and I'll get even further, they are what makes the strongest sense of 
> all the solutions it can get to.
>
> That is my one and only point, but I personally think it is enough to at 
> least discuss the issue.
>
> I have many questions from this point :
> - Has there been any discussions about that for Go2 yet? If yes, could any of 
> you point me to them?
> - What do you think about what I just wrote? Is it coherent and relevant or 
> am I missing something?
> - Do you see any alternative to the problem I brought here other than 
> authorizing circular imports?
> - Can anyone explain me exactly why circular imports are forbidden or is this 
> too complicated to hold in a mail?
>
> Thank you all for reading!
>
> --
> 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] Re: go modules and vendor: redundant features?

[Paul Jolly]

The main issue tracking vendoring-related discussion is
https://github.com/golang/go/issues/27227
On Thu, 22 Nov 2018 at 09:08,  wrote:
>
> Vendor must be kept for when dependencies are no longer available online.
>
> On Saturday, 17 November 2018 04:33:55 UTC, Henry wrote:
>>
>> Hi,
>>
>> It seems to me that go modules and vendor attempt to solve the same problem. 
>> I wonder whether we should just choose one and scrap the other, or find a 
>> way to consolidate them under a single unified feature. I am a bit concerned 
>> with the direction Go is going. People keep adding stuffs into Go and later 
>> find themselves unable to remove existing features due to the backward 
>> compatibility promise. Go 1.11 is a different beast than Go 1.0, and is 
>> significantly more complex.
>>
>> I think Go2 is an opportunity to learn from Go1, and to start from a clean 
>> slate by scraping and consolidating features. Go2 needs to be simpler than 
>> Go1.11
>>
>> Henry
>
> --
> 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] Using git-codereview with GitHub

[Paul Jolly]

> There is hub [1].  If you have not heard it, its work by
> repo-branch-commits,

Thanks, but as I understand it, this tool is branch-based.

I want to make my workflow oriented around single commits (on a local branch).


Paul

-- 
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] Using git-codereview with GitHub

[Paul Jolly]

Hi all,

Has anyone thought about/tried to get
https://godoc.org/golang.org/x/review/git-codereview working with a
GitHub backend?

What I'm ultimately trying to achieve is something akin to Gerrit's
relation chain. That is, have a number of commits on a local branch,
and have each commit correspond to a GitHub PR. Would involve creating
some PR-specific branches etc.

I realise there are some significant differences that might make this
infeasible/impractical, but thought I'd ask here as a starting point.

Thanks,


Paul

-- 
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 language sensitive editor?

[Paul Jolly]

> > To add to the responses below, a Language Server Protocol (LSP -
> > https://microsoft.github.io/language-server-protocol/) implementation
> > is also in the works
>
> Is there a link to share wrt 'in the works'?

Sorry, yes, that was needlessly vague.

We get updates from the Go tooling team on the golang-tools update
calls: https://github.com/golang/go/wiki/golang-tools

WIP implementation at https://github.com/golang/tools/tree/master/internal/lsp

-- 
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 language sensitive editor?

[Paul Jolly]

To add to the responses below, a Language Server Protocol (LSP -
https://microsoft.github.io/language-server-protocol/) implementation
is also in the works that will help to "level the playing field" for
language awareness between editors.

It will also make it possible to easily integrate new tooling like
vetters, linters etc, again in a way that is consistent (at least in
terms of protocol) between editors.On Tue, 20 Nov 2018 at 20:52, Pat
Farrell  wrote:
>
> I know, this is both a FAQ and an unanswerable question. I'm an old 
> programmer who has used nearly every editor known to man. I am not a fan of 
> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>
> What editors do folks use for go? I'd like something that can complete 
> function names, understand imports, and give some assistance.
>
> --
> 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] New Modules and git clones

[Paul Jolly]

> The `dev` in that documentation is intended to be a branch name. If that 
> module doesn't actually have a branch named `dev`, it won't work.

Thanks for humouring my stupidity :)

Because as if to reinforce the fact that I've never seen that help
document, I've also successfully demonstrated that I didn't actually
then read it: the paragraph after that example states quite clearly
that dev is a branch:

> The update rewrites non-canonical version identifiers to semver form,
> so A's v1 becomes v1.0.0 and E's dev becomes the pseudo-version for the
> latest commit on the dev branch, perhaps v0.0.0-20180523231146-b3f5c0f6e5f1.

-- 
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] New Modules and git clones

[Paul Jolly]

> > The `dev` in that documentation is intended to be a branch name. If that
> > module doesn't actually *have* a branch named `dev`, it won't work.

Thanks, Bryan.

> ...
>
> Hopefully there is a way of this getting updated as master/HEAD gets more
> commits.

Not automatically, no. go get X@master will bring you up-to-date.

https://github.com/golang/go/issues/26964 is about the ability to
track a branch in a more systematic way.

> Now I just have to find out why:
>
>module arcamclient
>
> is causing the error:
>
> can't load package: package arcamclient: unknown import path "arcamclient": 
> cannot find module providing package arcamclient

See https://github.com/golang/go/issues/27503#issuecomment-437052752


Paul

-- 
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] New Modules and git clones

[Paul Jolly]

> > Can you point us at the documentation you're referring to here, please?
>
>  go help go.mod

Thanks - it's honestly the first time I've a) read that help document
or b) seen the dev version format. I also can't find any tests
covering its usage.

Please can you raise an issue about the use of dev in this context,
via https://github.com/golang/go/issues/new? It's entirely possible I
am/we are missing something here, but no harm in checking.

For now, using any version < v2 should work, just so long as it is a
valid semver version that therefore doesn't require any further
resolution. e.g. v0.0.0 should be fine.

-- 
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] New Modules and git clones

[Paul Jolly]

> I recommend letting the go tool handle this. Leave the dependency out of the 
> go.mod file entirely. Run go build as normal, and it will automatically 
> determine the version strings for the dependencies and insert them into your 
> go.mod for you.

This won't work because per the original post, the dependencies have
not yet been pushed to their remote equivalents (or have any tags)

-- 
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] New Modules and git clones

[Paul Jolly]

> The documentation implies that I can use "dev" as the
> version number in the go.mod file for this situation

Can you point us at the documentation you're referring to here, please?

Thanks

-- 
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 modules and gocode

[Paul Jolly]

FWIW, the latest release of vim-go is working with modules for me
(it's not complete support but completion and go-to-def are working):

https://github.com/fatih/vim-go/blob/master/CHANGELOG.md#119---november-4-2018

Can I suggest we move this discussion to the vim-go issue tracker?

https://github.com/fatih/vim-go/issues/1906 is about modules support
in general. Given v1.19 has been released, it might make sense to open
a new issue with specific details of the issue you've seen.

Thanks


On Sun, 11 Nov 2018 at 16:28, Keith Brown  wrote:
>
> got it working.
>
> take a look at this
>
> https://github.com/keith6014/go/wiki/vim-go-setup
>
>
> On Friday, November 9, 2018 at 4:54:04 PM UTC-5, Tyler Compton wrote:
>>
>> My understanding is the mdempsky branch is not expected to work with Go 
>> modules. This fork apparently will: https://github.com/stamblerre/gocode
>>
>> That said, I haven't personally had any luck with that fork either. I would 
>> love to hear from someone who's had success with gocode/vim-go/modules.
>>
>> On Fri, Nov 9, 2018 at 1:03 PM Keith Brown  wrote:
>>>
>>> Using vim-go
>>>
>>> Has anyone gotten gocode (https://github.com/mdempsky/gocode) to work with 
>>> golang modules?
>>>
>>> In my GOPATH directory, i see
>>>
>>> gopath
>>>   pkg
>>> mod
>>>  cache
>>>download
>>>  github.com
>>>
>>> But for whatever reason, its not autocompletting the modules.
>>>
>>> Is there anything else I should be doing? In addion, is there a better 
>>> solution for vim users?
>>>
>>>
>>> --
>>> 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] what does the "replace" in go.mod mean?

[Paul Jolly]

> Maybe it's just me (and projects like the Stripe SDK and Blackfriday), but 
> that's exactly what I would expect.

Have you raised an issue/experience report with this feedback?

> Building source files is subject to build constraints, generating a go.mod 
> isn't (or shouldn't be; unless there's some reason I'm missing why you'd want 
> a go.mod file that's specific to an individual build with all its 
> constraints?).

No, I can't think of any reason why you would want a go.mod that is
specific to a set of build constraints. But to my mind that's a
slightly different point to whether a build command should have a side
effect beyond it's constraints.

That said I'd encourage you to file an issue/experience report,
because this is just my opinion/understanding of the reasoning behind
the current state.

-- 
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 does the "replace" in go.mod mean?

[Paul Jolly]

> I've just seen several projects do this wrong because they don't know about 
> go mod tidy so they build, let CI run tests (and don't notice that the file 
> has changed in CI), and call it a day never knowing that they're missing 
> dependencies. Since I can't imagine why you'd want to have partial 
> dependencies in the go.mod file (and even if you do, it's probably not nearly 
> as common as wanting all of them), the default behavior of go build seems 
> wrong to me.

Equally, I'm not sure that I would expect a command that is subject to
build constraints to do something beyond those constraints, which is
exactly what would happen under such a proposal.

-- 
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 does the "replace" in go.mod mean?

[Paul Jolly]

> > It does in as much as adding missing dependencies are concerned, but
> > doesn't do the tidying (removal) in go.{mod,sum} that go mod tidy
> > does.
>
> I don't think this is true (unless this has been fixed, I can't upgrade to 
> check right this moment), go build respects build constraints (eg. you won't 
> get dependencies that only exist in tests), so even if you're just talking 
> about adding missing dependencies, build won't necessarily help you.

I should have been more precise. go build adds missing dependencies
that are required to complete go build. Similarly for other build/test
related commands, e.g. go list. Those commands are, by definition, a
function of GOOS, GOARCH and build tag constraints. So yes, the only
dependencies that would be added with such a command would be those
required to complete that command under any such constraints.

go mod tidy is not a build command and so not subject to build
constraints, hence ends up adding missing dependencies irrespective of
build constraints.

I don't think there's anything wrong with this distinction - when you
say "unless this has been fixed", are you suggesting the behaviour is
wrong or could be improved in some respect?

> I've noticed this causing a lot of confusion in libraries moving to modules 
> where dependencies get left out because they're hidden behind a build tag, or 
> only get added when tests are run.

go mod tidy is the correct way to fix go.{mod,sum} to ensure they are
complete and minimal. https://github.com/golang/go/issues/27005 will
also be useful when it lands to make CI-esque checks easier.


Paul

-- 
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 does the "replace" in go.mod mean?

[Paul Jolly]

> 1. Why does "go build" still connect to go101.org even if the wording 
> "go101.org" doesn't appear in any source code and go.mod files?

That has been fixed in the CL associated with
https://github.com/golang/go/issues/27859, available on tip.

> 2. "Why doesn't "go build" run "go mod tidy" automatically?

It does in as much as adding missing dependencies are concerned, but
doesn't do the tidying (removal) in go.{mod,sum} that go mod tidy
does.

> 3. Now, each "go build" run will stil connect to go101.org firstly, even of 
> the replace line is there.
> Even if the connection fails, the build will still succeed. Then what the 
> meaningless to connect to
> the old import paths which have been replaced.

Correct. Per the issue above and indeed the more general
https://github.com/golang/go/issues/26241, this is a bug.

> 4. Why can't treat a replace line as require line automatically?

See https://github.com/golang/go/issues/26241

-- 
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 does the "replace" in go.mod mean?

[Paul Jolly]

> But the go101.org is not intended to serve any code repository.
> This is why I use the replace line in go.mod.

If go101.org will never resolve the custom import path (giving meta
information, as indicated at
https://golang.org/cmd/go/#hdr-Remote_import_paths), then why make
this the module path? Because anyone who uses the import path will
always have to add a replace. Why not make the module path
github.com/... in the first place? The replace directive is an
extremely inefficient alternative to custom import meta information.

> So my package import path must be locked as "github.com/" if go101.org 
> doesn't provide the repository meta?
> If this is true, I feel the go 1.11 module feature is not much useful.

Your example was almost there; you need a require statement, else when
the go tool encounters the go101.org/tinrouter import path it will try
to resolve that via custom import path resolution:

$ go version
go version go1.11.2 linux/amd64
$ cd $(mktemp -d)
$ go mod init blah
go: creating new go.mod: module blah
$ cat  github.com/go101/tinyrouter v1.0.0
$ go mod tidy
go: finding github.com/go101/tinyrouter v1.0.0
go: finding github.com/gorilla/mux v1.6.2
go: finding github.com/julienschmidt/httprouter
v0.0.0-20180715161854-348b672cd90d
...
$ cat go.mod
module blah

require (
github.com/davecgh/go-spew v1.1.1 // indirect
github.com/dimfeld/httptreemux v5.0.1+incompatible // indirect
github.com/gorilla/context v1.1.1 // indirect
github.com/pmezard/go-difflib v1.0.0 // indirect
github.com/stretchr/testify v1.2.2 // indirect
go101.org/tinyrouter v1.0.0
)

replace go101.org/tinyrouter => github.com/go101/tinyrouter v1.0.0
$ go build

-- 
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] require statements in multi module repositories

[Paul Jolly]

> I've played around with go modules in a multi module repository, and I'm 
> running into oddities. The main confusion is that I have this idea that any 
> package (and its subpackages) that has a go.mod file is a distinct, carved 
> out module that has no relation to its siblings and parent, even if they 
> happen to reside in the same repository and have their own go.mod files. That 
> does not seem to be the case, though.

You are correct. Locally, there are no constraints on the
containment/nesting of modules. That is to say, a module that exists
in a sub directory of another module does not need to share the same
path prefix.

In a remote VCS however, the containment is important if that VCS is
used as part of resolving a (custom) import path, and the go tool will
fail resolution if it not correct.

> Questions:
>
> If pkg_a depends on pkg_b, I expect the go.mod in pkg_a to contain "require 
> github.com/jadekler/module-testing/pkg_b". This does not happen when I `go 
> mod init && go mod tidy`. Is that WAI? Why?
> If pkg_c depends on the parent module, I expect the go.mod in pkg_c to 
> contain "require github.com/jadekler/module-testing". This does not happen 
> when I `go mod init && go mod tidy`. Is that WAI? Why?

I think these questions are answered in the GitHub issue you raised?

Please say if not.

Thanks,


Paul

-- 
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: One-liner README instructions for GitHub cross compiled binary assets

[Paul Jolly]

Thanks, I'll take a look.
On Wed, 31 Oct 2018 at 14:58, komuW  wrote:
>
> TJ's https://github.com/apex/up uses 
> https://github.com/goreleaser/godownloader  to generate `curl bash` style 
> downloads.
>
> On Wednesday, 31 October 2018 00:28:17 UTC+3, Paul Jolly wrote:
>>
>> Hi - I'm hoping someone can point me towards a "best practice" example on 
>> adding binary assets to GitHub releases of a program.
>>
>> Take https://github.com/myitcv/gobin/releases/tag/v0.0.2 as an example. I 
>> have added cross compiled binaries as assets to the v0.0.2 release.
>>
>> What I would now like to do is provide one-liner release instructions to the 
>> README for various OS's.
>>
>> One issue with the current approach is that when any of those binaries are 
>> downloaded the file is missing the execute permissions. That's easily 
>> fixable with chmod Or alternatively, I could upload archives instead of 
>> the binaries themselves...
>>
>> Indeed I'm sure there are plenty of other approaches.
>>
>> So I'm looking for advice on best practice, best practice that leads to the 
>> most sensible one-liner install instructions in READMEs.
>>
>> Any pointers much appreciated.
>>
>> Thanks,
>>
>>
>> Paul
>
> --
> 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] API to get the module name

[Paul Jolly]

Please see my response to your other email

On Wed, 7 Nov 2018, 04:23  Hi,
>
> Is there an API to get the module name of the current workspace?
>
> I was using code like below to read source files in a directory for codegen
>
> ``` pkg, err := build.Default.Import(directory, "", 0) ```
>
> with modules, packages are prefixed with module `name`. so, I may have to
> strip off it to build the path (directory)
>
> so, is there a way to read the module name, or a better way to import the
> package (build.Default.Import) without relying on GOPATH.
>
> thanks.
> bsr.
>
> --
> 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] Locate source code path (to import for code gen) of go module enabled project.

[Paul Jolly]

cc golang-tools

You need to be using https://godoc.org/golang.org/x/tools/go/packages in
place of go/build. It handles everything from import finding to type
checking.

Any further questions/problems please ask

On Wed, 7 Nov 2018, 04:35 bsr  How can I find the path (directory) of a package which uses go module
> (1.11).
>
> I had code (for  go:generate)  which uses package name to locate source
> code relative to GOPATH and import using
> https://golang.org/pkg/go/build/#Import
>
> Now, once I started using module, the package name is prefixed with module
> name and even if  I strip the module name, `build.Import` only look at
> GOROOT, and since no GOPATH is set, it won't search in the current package
> directory. using `os.Getwd` is not reliable as the source code is nested at
> different levels and can't reliably find the source.
>
> So, what is the best way to locate source (or the path ) based on package
> name of a go module enabled project.
>
> Any pointers greatly appreciated.
> thanks.
>
> --
> 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] One-liner README instructions for GitHub cross compiled binary assets

[Paul Jolly]

Hi - I'm hoping someone can point me towards a "best practice" example on 
adding binary assets to GitHub releases of a program.

Take https://github.com/myitcv/gobin/releases/tag/v0.0.2 as an example. I 
have added cross compiled binaries as assets to the v0.0.2 release. 

What I would now like to do is provide one-liner release instructions to 
the README for various OS's.

One issue with the current approach is that when any of those binaries are 
downloaded the file is missing the execute permissions. That's easily 
fixable with chmod Or alternatively, I could upload archives instead of 
the binaries themselves... 

Indeed I'm sure there are plenty of other approaches.

So I'm looking for advice on best practice, best practice that leads to the 
most sensible one-liner install instructions in READMEs.

Any pointers much appreciated.

Thanks,


Paul

-- 
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 modules and replace

[Paul Jolly]

Actually, now that I think about it, this restriction was relaxed. So
the dot in the first part of the path is not a requirement.

It appears however that go mod edit has partially regressed in this respect.

Please can you raise an issue? That way we can have the behaviour
confirmed one way or the other.

Thanks
On Sat, 20 Oct 2018 at 00:44, Mark Volkmann  wrote:
>
> I see though that "go mode edit" really wants there to be a dot in the first 
> part of the import path.
> Where can I read about that requirement?
>
> On Fri, Oct 19, 2018 at 6:30 PM Mark Volkmann  
> wrote:
>>
>> Thank you so much! I actually got it to work without having a dot in the 
>> first part of the import path.
>> It seems the only thing I was missing was this line in mod.go for the demo 
>> code:
>> require foo/bar v0.0.0
>> I just had the replace directive line without a corresponding require 
>> directive.
>>
>> On Fri, Oct 19, 2018 at 6:13 PM Paul Jolly  wrote:
>>>
>>> Hi Mark,
>>>
>>> When importing a module package, the first element in the path must
>>> contain a ".". Hence "foo" is invalid. Here is a working example:
>>>
>>> $ cd $HOME
>>> $ mkdir bar
>>> $ cd bar
>>> $ go mod init example.com/bar
>>> go: creating new go.mod: module example.com/bar
>>> $ cat <bar.go
>>> package bar
>>> import "fmt"
>>> func Hello() {
>>> fmt.Println("Hello from bar!")
>>> }
>>> EOD
>>> $ cd $HOME
>>> $ mkdir foo
>>> $ cd foo
>>> $ go mod init example.com/foo
>>> go: creating new go.mod: module example.com/foo
>>> $ cat <main.go
>>> package main
>>>
>>> import "example.com/bar"
>>>
>>> func main() {
>>> bar.Hello()
>>> }
>>> EOD
>>> $ go mod edit -require=example.com/bar@v0.0.0 
>>> -replace=example.com/bar=$HOME/bar
>>> $ cat go.mod
>>> module example.com/foo
>>>
>>> require example.com/bar v0.0.0
>>>
>>> replace example.com/bar => /root/bar
>>> $ go run .
>>> Hello from bar!
>>> On Fri, 19 Oct 2018 at 21:42, Mark Volkmann  
>>> wrote:
>>> >
>>> > I have a simple demo application that wants to use a package that is on 
>>> > my local file system.
>>> > The code for the package is in /Users/Mark/foo/bar.
>>> > This directory contains the file bar.go which contains:
>>> >
>>> > package bar
>>> > import "fmt"
>>> > func Hello() {
>>> > fmt.Println("Hello from bar!")
>>> > }
>>> >
>>> > It also contains the file go.mod which just contains:
>>> >
>>> > module bar
>>> >
>>> > The demo application in another directory imports this as "foo/bar" in 
>>> > the file main.go.
>>> > It has a go.mod file that contains the following:
>>> >
>>> > module demo
>>> > replace foo/bar => /Users/Mark/foo/bar
>>> >
>>> > When I enter "go run main.go" in the directory of the demo code I get
>>> > build demo: cannot find module for path foo/bar
>>> >
>>> > Is there something wrong with my use of the "replace" directive?
>>> >
>>> > None of this code is under the directory pointed to by GOPATH because I'm 
>>> > trying to use Go modules for everything in this demo.
>>> >
>>> > --
>>> > R. Mark Volkmann
>>> > Object Computing, Inc.
>>> >
>>> > --
>>> > 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.
>>
>>
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.

-- 
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 modules and replace

[Paul Jolly]

Hi Mark,

When importing a module package, the first element in the path must
contain a ".". Hence "foo" is invalid. Here is a working example:

$ cd $HOME
$ mkdir bar
$ cd bar
$ go mod init example.com/bar
go: creating new go.mod: module example.com/bar
$ cat  /root/bar
$ go run .
Hello from bar!
On Fri, 19 Oct 2018 at 21:42, Mark Volkmann  wrote:
>
> I have a simple demo application that wants to use a package that is on my 
> local file system.
> The code for the package is in /Users/Mark/foo/bar.
> This directory contains the file bar.go which contains:
>
> package bar
> import "fmt"
> func Hello() {
> fmt.Println("Hello from bar!")
> }
>
> It also contains the file go.mod which just contains:
>
> module bar
>
> The demo application in another directory imports this as "foo/bar" in the 
> file main.go.
> It has a go.mod file that contains the following:
>
> module demo
> replace foo/bar => /Users/Mark/foo/bar
>
> When I enter "go run main.go" in the directory of the demo code I get
> build demo: cannot find module for path foo/bar
>
> Is there something wrong with my use of the "replace" directive?
>
> None of this code is under the directory pointed to by GOPATH because I'm 
> trying to use Go modules for everything in this demo.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> 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] Should you commit a 'go.mod' file that contains a Replace directive to a repository?

[Paul Jolly]

This is being discussed in https://github.com/golang/go/issues/26640
On Sun, 14 Oct 2018 at 12:48, 'kalekold' via golang-nuts
 wrote:
>
> When should you use the Replace directive in a 'go.mod' file?
> Is this feature only useful for debugging and development?
>
> The reason I ask is that you can use the Replace directive to point to an 
> arbitrary location on disk as well as a normal downloaded package. So does 
> that mean that committing a 'go.mod' file that contains a Replace directive 
> to a repo is bad practice? Because consumers of that repo might not have the 
> replacement source.
>
> --
> 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] Visit London

[Paul Jolly]

Hi everyone,

London is famous for many things: the Royal Family, Buckingham Palace,
people standing in queues, Big Ben, the lack of air conditioning in
theatres, musicals. We could go on.

But did you know it's also famous for the Go London User Group (GLUG),
aka London Gophers?? :)

With over 2500 members, we meet on a monthly basis to enjoy:

* talks and chat about all-things Go
* good food and drink
* great company amongst friends

A key focus of London Gophers is to be an open, welcoming and
supportive community for anyone interested in Go. All of our events
fall under the Go Code of Conduct (https://golang.org/conduct) and we
are big fans of the Gopher Values (https://golang.org/conduct#values).

So if you are in town and would like to come and join us at one of our
meetups, you'd be more than welcome! Our next meetup is on Wed 17
October:

https://www.meetup.com/Go-London-User-Group/events/255136575/

Unfortunately we’re already full for October - 150 people signed up in
under 2 hours, with >150 people on the waitlist!  So follow us on
Twitter (https://twitter.com/LondonGophers) and join the Meetup group
(https://www.meetup.com/Go-London-User-Group/) for news about future
meetups.

We live-stream the talks from each meetup, and videos from past
meetups can be found on YouTube (https://youtube.com/c/LondonGophers).

Better still, if you are in town and would like to give a talk at one
of our meetups, let's get you booked in! First-time speakers are
especially welcome - we can help with refining your topic, preparing
the talk/format/slides etc. Please get in touch via
glug-organis...@googlegroups.com.

Thanks,


Paul and the GLUG Team

-- 
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 mod download -json` does not product valid json?

[Paul Jolly]

> It looks like it is a stream of JSON objects?
>
> If so, I suspect this is expected?

Per the issue you linked, thepudds, absolutely correct.

This comment gives details on how to handle such a stream of JSON objects:

https://github.com/golang/go/issues/27655#issuecomment-420993215


Paul

-- 
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 mod: how to develop in multiple repos?

[Paul Jolly]

See https://github.com/golang/go/issues/26640

On Mon, 1 Oct 2018, 23:10 Dan Kortschak, 
wrote:

> Is there an issue for this; it continues to fill me with dread that
> temporary edits to committed files are intended to be part of a
> development workflow.
>
> On Fri, 2018-09-28 at 06:24 -0700, Tamás Gulácsi wrote:
> > Use the replace directive with relative path.
> >
>
> --
> 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 mod tidy pulls in too much

[Paul Jolly]

Hi Harmen

I described the problem on https://github.com/golang/go/issues/27920, which
> got
> closed within three minutes as being "documented", and "works as
> expected" (which I assume also means "works as intended").
> Is this really the intented behaviour? It seems unexpected to me. Or
> should I
> simply stay away from `go mod tidy`?
>

I replied to your issue earlier. But could arguably have been slightly more
detailed in my response beyond simply linking to
https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-indirect-and-test-dependencies-in-my-gomod

As you note, github.com/hashicorp/consul/api is a package. It is a package
in the module github.com/hashicorp/consul. Despite there being no go.mod in
github.com/hashicorp/consul, the go tool simulates it as a module.

Given there are no go.mod files in any subdirectories below
github.com/hashicorp/consul, then github.com/hashicorp/consul is the module
for all the packages github.com/hashicorp/consul/...

Hence go mod tidy (per the link in my response to your issue) is pulling
in the transitive dependencies needed for tests in
github.com/hashicorp/consul/... The reason you see all of these in your
go.mod is that github.com/hashicorp/consul has not yet been converted to a
module as yet.

Hopefully that gives a bit more colour on what's going on here.

Thanks,


Paul

>

-- 
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] Dependency resolution weirdness with Go Modules.

[Paul Jolly]

Looks related to https://github.com/golang/go/issues/27457.

Perhaps a variation of
https://github.com/golang/go/issues/27457#issuecomment-419364867 helps
in this situation?
On Thu, 27 Sep 2018 at 00:51, Josh Harshman  wrote:
>
> Using Go 1.11 and Go Modules to resolve package dependencies for my project.
> Unfortunately I am running into some vendoring issues and incompatibilities 
> that have me a little stumped.
>
> Here is my go.mod file, there are a few packages listed as incompatible etc...
> go.mod
> module github.ancestry.com/Ancestry/platform-haas
>
> require (
> github.com/BurntSushi/toml v0.3.1 // indirect
> github.com/Masterminds/semver v1.4.2 // indirect
> github.com/Masterminds/sprig v2.16.0+incompatible // indirect
> github.com/aokoli/goutils v1.0.1 // indirect
> github.com/docker/distribution v2.6.2+incompatible // indirect
> github.com/ghodss/yaml v1.0.0 // indirect
> github.com/gobwas/glob v0.2.3 // indirect
> github.com/gogo/protobuf v1.1.1 // indirect
> github.com/golang/mock v1.1.1
> github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db // 
> indirect
> github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // 
> indirect
> github.com/google/uuid v1.0.0 // indirect
> github.com/gorilla/mux v1.6.2
> github.com/hashicorp/errwrap v1.0.0 // indirect
> github.com/hashicorp/go-cleanhttp v0.5.0
> github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90
> github.com/hashicorp/go-sockaddr v0.0.0-20180320115054-6d291a969b86 
> // indirect
> github.com/hashicorp/vault v0.11.1
> github.com/huandu/xstrings v1.2.0 // indirect
> github.com/imdario/mergo v0.3.6 // indirect
> github.com/json-iterator/go v1.1.5 // indirect
> github.com/mitchellh/go-homedir v1.0.0
> github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // 
> indirect
> github.com/modern-go/reflect2 v1.0.1 // indirect
> github.com/ryanuber/go-glob v0.0.0-20170128012129-256dc444b735 // 
> indirect
> github.com/sethgrid/pester v0.0.0-20180430140037-03e26c9abbbf
> github.com/sirupsen/logrus v1.1.0
> github.com/spf13/cobra v0.0.3
> github.com/spf13/viper v1.2.0
> golang.org/x/net v0.0.0-20180926154720-4dfa2610cdf3
> golang.org/x/time v0.0.0-20180412165947-fbb02b2291d2 // indirect
> google.golang.org/grpc v1.15.0 // indirect
> gopkg.in/inf.v0 v0.9.1 // indirect
> gopkg.in/yaml.v2 v2.2.1
> k8s.io/api v0.0.0-20180925152912-a191abe0b71e // indirect
> k8s.io/apiextensions-apiserver v0.0.0-20180925155151-c0b566b8903b // 
> indirect
> k8s.io/apimachinery v0.0.0-20180925152725-5ae511e0ed34 // indirect
> k8s.io/apiserver v0.0.0-20180925200106-4eecb3917976 // indirect
> k8s.io/client-go v8.0.0+incompatible // indirect
> k8s.io/helm v2.11.0+incompatible
> k8s.io/kubernetes v1.11.3 // indirect
> )
>
>
> and predicibly I suppose when running go build ./... I receive the following 
> errors.
>
> ...[snip]...
>
> # k8s.io/client-go/pkg/apis/clientauthentication/v1alpha1
> /go/pkg/mod/k8s.io/client-go@v8.0.0+incompatible/pkg/apis/clientauthentication/v1alpha1/zz_generated.conversion.go:39:15:
>  scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs)
> # k8s.io/client-go/pkg/apis/clientauthentication/v1beta1
> /go/pkg/mod/k8s.io/client-go@v8.0.0+incompatible/pkg/apis/clientauthentication/v1beta1/zz_generated.conversion.go:39:15:
>  scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs)
> # k8s.io/kubernetes/pkg/util/parsers
> /go/pkg/mod/k8s.io/kubernetes@v1.11.3/pkg/util/parsers/parsers.go:36:16: 
> undefined: reference.ParseNormalizedNamed
> # k8s.io/kubernetes/pkg/apis/admissionregistration/v1alpha1
> /go/pkg/mod/k8s.io/kubernetes@v1.11.3/pkg/apis/admissionregistration/v1alpha1/zz_generated.conversion.go:39:15:
>  scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs)
> # k8s.io/kubernetes/pkg/apis/admissionregistration/v1beta1
> /go/pkg/mod/k8s.io/kubernetes@v1.11.3/pkg/apis/admissionregistration/v1beta1/zz_generated.conversion.go:40:15:
>  scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs)
> # k8s.io/kubernetes/pkg/apis/authentication/v1
> /go/pkg/mod/k8s.io/kubernetes@v1.11.3/pkg/apis/authentication/v1/zz_generated.conversion.go:41:15:
>  scheme.AddGeneratedConversionFuncs undefined (type *runtime.Scheme has no 
> field or method AddGeneratedConversionFuncs)
> # k8s.io/kubernetes/pkg/apis/authentication/v1beta1
> /go/pkg/mod/k8s.io/kubernetes@v1.11.3/pkg/apis/authentication/v1beta1/zz_generated.conversion.go:39:15:
>  scheme.AddG

Re: [go-nuts] Re: When using 'go mod vendor' why are there lots of files missing?

[Paul Jolly]

> I think it's worth raising an issue for this. Vendoring should copy the whole 
> repo.

This has been raised before (https://github.com/golang/go/issues/26366
amongst others). Vendoring is not defined to copy the whole repo:

$ go help mod vendor
usage: go mod vendor [-v]

Vendor resets the main module's vendor directory to include all packages
needed to build and test all the main module's packages.
It does not include test code for vendored packages.

An alternative is to "vendor" the modules themselves:

https://github.com/myitcv/go-modules-by-example/blob/master/012_modvendor/README.md

-- 
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: Using modules with go test ./...

[Paul Jolly]

John,

Scott is on the money with this response:

> I think you need to have a main module defined so there must be a go.mod in 
> cwd or upwards

The way to ensure that you are in a valid module context is simply:

go env GOMOD

which will return the path to the current (or main) module context (go.mod) if:

a) you are in module mode (either by being outside of GOPATH or with
GO111MODULE=on) and
b) there is a go.mod on the directory path from $PWD to the root.

As you have set GO111MODULE=on you can put your source code pretty
much anywhere you like; even within your GOPATH (whether GOPATH is set
or not, in the latter case as has been pointed out it defaults to
$HOME/go)

All you are missing is a go.mod file (go end GOMOD would confirm this,
and would return "")

Here's a simple example that shows things working within GOPATH:

$ export GO111MODULE=on
$ export GOPATH=/tmp/tmp.JJgvIDI0Uc
$ cd /tmp/tmp.In4INnkIH0
$ mkdir -p src/example.com/blah
$ cd src/example.com/blah/
$ cat 

Re: [go-nuts] Re: using go modules replace with old repos

[Paul Jolly]

Hi John,

When using a replace target that is a local filepath, yes, the target
does need to be a module (this is in effect simulated by the go tool
when a "module" is fetched from a remote VCS in case a project is not
a module).

That's fixed in the most simple cases by creating a go.mod file in the
target directory, either:

go mod init
go mod init example.com/blah

Depending on your workflow, you might also be interested in
https://github.com/rogpeppe/gohack which was created to experiment
with workflows around working on local module replace-ments.

Thanks,


Paul
On Fri, 14 Sep 2018 at 15:08, John Shahid  wrote:
>
>
> Ping.
>
> John Shahid  writes:
>
> > Hi all,
> >
> > Is there a way to use the go module `replace' directive for packages
> > that don't have go.mod yet ? I tried doing that and I get the following
> > error:
> >
> >> go: parsing ../pkg/go.mod: open /path/to/pkg/go.mod: no such file or
> >> directory
> >
> > According to https://github.com/golang/go/issues/24110 it looks like
> > this is the intended behavior.  My question is why the go tool (e.g. go
> > get) can deal with such package when downloading it from github and
> > could give it a pseudo version without a go.mod file but refuses to when
> > the source code is local.
> >
> > I'm happy to construct a sample github project to repro the issue if
> > that is needed.
> >
> > Thanks,
> >
> > -js
>
> --
> 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] Is it possible to build a module without a hosted repository?

[Paul Jolly]

Perhaps just for completeness here, the replace directive is almost
certainly what you want when it comes to unpublished modules. This
will allow you to refer to a remote module as if it were published,
even though it resides on a local disk.

See go help mod edit for more details (or alternatively
https://tip.golang.org/cmd/go/#hdr-Edit_go_mod_from_tools_or_scripts)

The one open issue to bear in mind however is
https://github.com/golang/go/issues/26241
On Sat, 15 Sep 2018 at 17:07, K Davidson  wrote:
>
> Well, my embarrassingly incorrect assumption came about from a package I was 
> writing recently; I was using the go mod tool to initialize my go.mod rather 
> than writing the file myself, and as an import statement I first tried using 
> the local filepath, which of coarse didn't work. Then I tried things like: 
> "." (yielding error: unknown import path "_/home/k/code/go/delete": internal 
> error: module loader did not resolve import" upon build (but it let me 
> initialize the module without issue). What finally did work, was when I used 
> a GitHub repo URL that I created only for this purpose, which is what 
> ultimately brought about my assumption. It never occurred to me to use a 
> fictitious import path because, well, there is nothing there.
>
> So it was my mistake (*egg on my face ¯\_(ツ)_/¯)
>
> But thx for the replies.
>
> -K
>
> --
> 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] modules and package cyclic dips

[Paul Jolly]

> First, my overall point is that I have decided to use only acyclic 
> dependencies, as cyclic ones are too complicated for me.
> I don't feel easily convincible otherwise; that comes from a combination of 
> using go modules where some cycles crept in
> and a strong bias for a dead simple dependency methodology.

That's totally fine, with the slight caveat being that in some cases
they're unavoidable (e.g. the GopherJS case).

I've drafted a guide that presents what I hope is a simpler example of
a cyclic dependency:

https://github.com/myitcv/go-modules-by-example/tree/013_cyclic/013_cyclic

One point to note is that this example will become simpler still once
https://github.com/golang/go/issues/26241 is resolved.

Would appreciate any feedback, but please don't feel obliged.

I fear it may take a few iterations to get the wording/emphasis right...

Thanks,


Paul

-- 
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] Modules + go get

[Paul Jolly]

>> GO111MODULE=off go get -u github.com/my/package
>
> Last time I check, if GOPATH is unset and GO111MODULE is on it will download 
> the source code to $HOME/go.

If you saw this behaviour then that is a bug. Or did you mean
GO111MODULE=auto or GO111MODULE is unset (in addition to GOPATH being
unset)?

If you have any repro steps that would be useful.

-- 
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] Modules + go get

[Paul Jolly]

This sort of "global" get/install is being discussed in
https://github.com/golang/go/issues/24250 (which will also cover the
documentation point). It's marked as "release blocked" for Go 1.12.

For now, I think the best approach is to:

GO111MODULE=off go get -u github.com/my/package

i.e. drop back to GOPATH-mode. You can optionally set GOBIN as you
suggest, but not necessary because GOPATH will default to $HOME/go


Paul
On Mon, 10 Sep 2018 at 09:41, Caleb Spare  wrote:
>
> What's the best substitute for "go get my/tool" in a modules world?
>
> I used to be able to tell my users to set up Go with a GOPATH workspace and 
> then run "go get -u github.com/my/package". I can't find an equivalent 
> workflow now. The closest I can find is
>
> GOBIN=~/bin GO111MODULES=on go get github.com/my/package@latest
>
> But this drops go.mod/go.sum files in the current directory, which I don't 
> want. Is there some command to just build and put a binary in a directory 
> without touching any other files (outside the cache)?
>
> --
> 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] modules and package cyclic dips

[Paul Jolly]

Hi Scott,

> Yes I see that in terms of compatibility it "all works out", but it seems
> underspecified what should happen.

Which bit do you think is underspecified?

To my mind the behaviour is very clearly defined, notwithstanding the
next point.

> Also, although your experience reports are
> clearly presented and make sense, when I step back my own impression
> is: that's not simple.

That's certainly true. But...

> I'd rather be spending time coding than figuring out
> or worrying about chains of cyclic dependencies going back in time 
> indefinitely.

As would I, but I think in some situations these cycles are
unavoidable, assuming you can't collapse the two modules down into one
(and in the GopherJS we can't).

Thanks,


Paul

-- 
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] modules and package cyclic dips

[Paul Jolly]

> Interesting.  I'm not sure what cyclic module dependencies means.  I do know 
> some package managers (not go) boast of having a "solid transitive dependency 
> model".  I hope that any cycles in modules dependencies are either avoided or 
> treated in a very clear simple way by go's modules.

In my experience report I explain how the situation comes about in the
case of GopherJS. The "reverse" dependency (i.e. the one that makes
the cycle) is, I suspect, typically (always?) going to be something to
do with testing.

> Unfortunately, my concrete example is lost in sands of time, so I can only 
> give a rough idea.  I had cyclic module dependencies, somewhat unintended, 
> but it crept in via some test case.  I was playing with 111 or late 111 
> release candidate with it and asked it to rebuild go.mod at an untagged HEAD 
> (I think) that was a few commits ahead of say v0.1.2.  Then go.mod had that 
> my module required v0.1.1 of itself in go.mod "indirectly".  All I could 
> figure out was that the module dependency cycle A -> B -> A had B depending 
> on an older version of A via a test case.

I suppose you could say that transitively this module depends on the
same major version of itself, yes.

The same is true in my experience report. And it's by definition that
you end up with a reference to and "older" version because of the
existence dependence of the modules.

But because of semantic import versioning (i.e. same major version in
this situation) and compatibility within that major version,
everything works out, even when running go test all from either of the
modules involved in the cycle.

I found this easiest to reason about by looking at the process
involved with _introducing_ the submodule in the GopherJS repo that
creates the cycle:

https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46fd5#the-process


Paul

-- 
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] modules and package cyclic dips

[Paul Jolly]

Hi Scott,

> Should cyclic module dependencies be allowed?

Yes, indeed in some situations they are totally necessary.

I wrote up an experience report on this very topic:
https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46fd5

> Should a module, following a cycle, be able to depend on an earlier version 
> of itself? (I saw this once...)

I can't see how this would work; indeed I can't even unravel it in my
head! Do you have a concrete example to help explain?

Thanks,


Paul

-- 
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-mod] sub-modules & required Go version

[Paul Jolly]

> 2) what's the story with "submodules" ?

Submodules work. But if you can get away with just a single module,
then do :) Because submodules are dependencies nonetheless, and with
them comes the overhead of managing those dependencies. Clearly with
modules that process is made much simpler, but there's still overhead.
The process of managing those dependencies is different compared to
them living in separate repos (in some respects it's more fiddly); but
it's still a process that needs to be followed vs no process at all
(because everything is on the same version "train")

In case it's of any use (you sent your message some time ago):
https://github.com/myitcv/go-modules-by-example/blob/master/009_submodules/README.md

-- 
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: Local repository for go modules

[Paul Jolly]

>
> I think you could go down the Athens path if you wanted to, but I don't 
> think you need to do so.
>

See 
also https://groups.google.com/forum/#!msg/golang-dev/mNedL5rYLCs/OGjRDTmWBgAJ 

-- 
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] Local cache of dependencies

[Paul Jolly]

See also https://groups.google.com/d/msg/golang-dev/mNedL5rYLCs/OGjRDTmWBgAJ
On Wed, 22 Aug 2018 at 23:34, Conor Hackett  wrote:
>
> Hey Guys,
>
> So, adding your "vendor" directory to SCM is a contentious topic at best.
>
> I personally would rather not vendor the dependencies but I do need to keep 
> the required code in my control and I consider third party repos out of my 
> control.
>
> Similar to how maven works (and others I am sure), is there some tooling that 
> will enable me to cache/store/save third party dependencies on my local 
> machine/server etc in order to
>
> a) reduce operational risk of a repo/code disappearing
> b) potentially speeding up build time
>
> This post is more of a sanity check -- I have been searching for such tooling 
> for a while now and am about to spin up a new project do something along 
> these lines.
>
> Thanks in advance.
>
> --
> 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 modules introspection

[Paul Jolly]

Hi Jens,

> Is there a clean way to identify if the current working directory is a go 
> module and to get module information from go.mod (i.e. a parser fo go.mod 
> files)?

go env GOMOD

> I did seach the documentation on golang.org but could not find any 
> information.

Depends on what you want. If you want the go.mod file itself you'll want:

go mod edit -json

Else if you want details about the dependencies:

go list -m all

Thanks,


Paul

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