Hi Tim,
Take a look at https://golang.org/ref/spec#Calls:
"A method call x.m() is valid if the method set of (the type of) x contains
m and the argument list can be assigned to the parameter list of m. If x is
addressable and &x's method set contains m, x.m() is shorthand for (&x).m()"
Paul
On
Speaking as someone who has written a few (albeit simple) code generators
that parse Go code, dot imports are a nightmare from my perspective because
it makes it impossible to work out from just imports alone whether an
identifier belongs to the current package or not.
Put another way, if you disa
See https://github.com/golang/go/issues/14106
On 9 April 2018 at 19:40, Glen Newton wrote:
> Hello,
>
> I was wondering why os.File is a struct and not an interface. It does not
> expose anything except methods.
>
> I was wanting to make a mock os.File for testing and other purposes, but
> it no
I think you're getting at something similar to:
https://docs.google.com/document/d/1Ee8POHVeo3N6c1pgiubdWoUJoYkD5cwY3p8rqonRY0o/edit
Implemented roughly here:
https://github.com/myitcv/go
This was itself similar to/influenced by:
https://github.com/golang/go/issues/17271#issuecomment-268301191
Or, just for completeness, https://github.com/cxreg/smartcd
On 20 April 2018 at 13:45, unknown wrote:
>
> You can use direnv[1] to achieve what you want
>
> [1]: https://direnv.net/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To uns
Tangentially related (I think): https://github.com/golang/go/issues/24751
On Tue, 22 May 2018 at 19:10, Nate Finch wrote:
> Forgive me if this has been answered somewhere. I tried to divine it from
> Russ' documents, but I couldn't really tell.
>
> Do vanity imports change dramatically with vgo
This was also raised in https://github.com/golang/go/issues/24506 and
is being fixed in the linked CL
On Tue, 7 Aug 2018 at 06:33, John More wrote:
>
> You are right, using the -i option did the deed.
> Thanks
> John
>
> On Tue, Aug 7, 2018 at 1:26 AM, Ian Lance Taylor wrote:
>>
>> On Mon, Aug 6,
de julho de 2018 12:05:18 UTC-3, Paul Jolly escreveu:
>>
>> Just a quick check: what version of git are you using?
>
>
> $ git --version
> git version 2.17.1
>
> $ go version
> go version go1.11beta2 linux/amd64
>
>
> --
> You received this message beca
pository
>>> that has a couple of separate but related/dependent packages. The repo is
>>> still in my standard GOPATH. When I try to build one of the sub modules
>>> that is dependent on a peer module it downloads an older version of the
>>> repository an
And incidentally, #modules on Gophers Slack will likely be a better
place to work things through; it's got a great number of people
helping/responding.
On Wed, 8 Aug 2018 at 17:28, Paul Jolly wrote:
>
> Cole - apologies, things got busy in the last few weeks so this thread
>
Hi Sam,
> This thread is of great importance to a lot of people in the community, and
> the information you can get from it is very important. Please do not move it
> to a closed system like Slack. Not everyone can get a Slack account to
> participate, or even read any discussion that happens t
>
>
> I can no longer see the issue in beta2 or beta3... AFAICT modules are
> working like a charm.
>
Great!
--
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 gola
> I wonder how in a world of go modules without a GOPATH,
> code completion within editors is supposed to be implemented?
This is covered by https://github.com/golang/go/issues/24661.
In short, tools like gocode (which is the most commonly used
code-completion engine to my knowledge) would likely
Hi Benny,
> if I understand correctly, the plan with versioned packages and modules is to
> deprecate the vendor folder and GOPATH some time after Go 1.11.
That is true of GOPATH; the case is less clear-cut with vendor. See
also the discussion about vendor as part of:
https://github.com/golang/
Hi Tim,
There happens to have been a discussion about this recently on Twitter
(see https://twitter.com/_myitcv/status/1032836284987977729)
Take a look at https://github.com/rsc/goversion
The -m flag should give you details of the modules used to build your program.
Thanks,
Paul
On Fri, 24 Au
Please see https://github.com/golang/gddo/issues/567
On Tue, 28 Aug 2018, 18:59 Justin Israel, wrote:
> I've been trying out converting some of our internal projects to go 1.11
> using modules instead of glide. We have a build system that provides the
> ability to generate html docs via "godoc"
18 at 07:46, wilk wrote:
>
>
> It could be fine to start a wiki page to list the tools and ide
> (not)ready for modules with the linked issues.
>
> In https://github.com/golang/go/wiki/Modules or a new page ?
>
> On 29-08-2018, Paul Jolly wrote:
> > --5012
go
>> doc".
>
>
> Fair enough. I should just discontinue the feature we have in our build
> systems Go tool. It was neat to generate html docs with our deploys.
>
>>
>> - Agniva
>>
>>
>> On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justi
Please can you share details of the project, and/or repro steps?
On Sun, 2 Sep 2018 at 12:58, Kaveh Shahbazian
wrote:
>
> A required modules is added to my go.mod file with version v2.0.0 - which I
> expect to give me the v2.1.0.
>
> But after running go mod tidy the version inside go.mod file be
The v2 of the module needs a /v2 suffix on the module name in go.mod:
https://github.com/dc0d/farsi/blob/a31316716e58115e7f7eb987d4e6476aa092cbab/go.mod#L1
You should then be set.
On Sun, 2 Sep 2018 at 13:07, Kaveh Shahbazian
wrote:
>
> Sure!
>
> This is the module that is being imported: https:
The main thing to remember is (from go help modules):
> A module is a collection of related Go packages.
> Modules are the unit of source code interchange and versioning.
Your module import path is github.com/dc0d/farsi.
Your module's v2 import path is github.com/dc0d/farsi/v2
etc.
Any packages
I suspect that you've just run into some variation on
https://github.com/golang/go/issues/27378
Giovanni/Daniel/others better placed might be able to confirm more
precisely however.
On Mon, 3 Sep 2018 at 17:49, wrote:
>
> Hi all,
>
> Since Go 1.11, the following test seems to pass when I would
>
> *Question 1*: are calls from JS into Go/WASM expected to be asynchronous?
> If so, is the callback passing approach the best way to get return values
> back to the JS code?
>
Please see https://github.com/golang/go/issues/26045. Yes they are
currently async, but they will become sync
--
You
Just cross referencing with
https://github.com/golang/go/issues/24661#issuecomment-418211394
On Tue, 4 Sep 2018 at 17:33, Jens-Uwe Mager wrote:
>
> I am using the godoc command to get the complete documentaion of a package
> vs. the short form the go doc normally generates. For example the follow
See https://github.com/golang/go/issues/26993 and
https://github.com/golang/go/issues/26988, specifically
https://github.com/golang/go/issues/26988#issuecomment-417886417
On Tue, 4 Sep 2018 at 12:24, Volker Dobler wrote:
>
> Has anybody experience the same behaviour?
> Am I doing something wrong?
For "global" installs of a tool via go (get|install), this is indeed a
critical feature and is covered by
https://github.com/golang/go/issues/24250. ("global" is defined as:
outside of a module context (i.e. no go.mod), with GO111MODULE=on)
Within a module context, i.e. with a go.mod present, go (
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
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 kee
>
> 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 un
> 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 the
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
> 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
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
> c
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 bac
>> 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
un
> 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 depende
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
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 t
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 (g
> 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
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 p
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
> shoul
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
> 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
--
Y
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 250
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 u
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
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 &
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
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
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 mod
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
> 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
> 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
> 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" auto
> > 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 (e
> 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 part
> 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
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
> 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 uns
> 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
> > 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 d
> > 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@maste
> 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 tha
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 tool
> > 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 o
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 correspon
> 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 Googl
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
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/0
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
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 201
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/api
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 unsubscrib
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
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 ma
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 recei
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 cours
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/tre
>
> 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
(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
gt;
> 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 module
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 e
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 com
Take a look at unused:
https://github.com/dominikh/go-tools
That will help you to eliminate unused code pre compile time.
On 23 Jan 2018 13:38, "Patrik Iselind" wrote:
> Hi guys,
>
> Is there a way to get `go install` to error out if there is unused
> functions in the code base? This should of
gle. (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 some
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
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
anks 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-Mo
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 thi
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:
>
>
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
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
> 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 runni
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
dat
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
Please can someone can enlighten me or point me towards relevant docs/other
regarding the design decisions behind time.Time?
Specifically why the concept of an instant in time, referenced many times
throughout the time docs, was not encoded as a type itself:
type Instant struct {
sec int64
>
> > The sec and nsec fields in a time.Time are relative to the Unix epoch
> and so
> > denote a point in time by themselves. The location is merely for
> > presentation.
>
> Pedantically, they are not relative to the Unix epoch. They are
> relative to January 1, year 1, 00:00:00.0
Hi - wondering whether anyone knows of any tooling that helps with
"pipelines" (probably not a great choice of phrase) of go generate-able
code.
Specifically the case where the output of one go generate program is code
which is itself go generate-able (and hence requires another invocation of
Thanks for the feedback.
> You would need to write the programs go generate is calling to be
> idempotent, and have the second one exit quietly if the first hasn't run.
> You would then either run go generate twice or have the first program run
> go generate once it had completed.
>
Regarding su
1 - 100 of 158 matches
Mail list logo
