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:
>
>
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
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
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:
>> 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
> 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.
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
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
> 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.
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
> 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
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 Jol
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
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
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
>
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
> 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
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
> 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
> 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
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
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
>> 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
> "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(). The
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
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.
> 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
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
> 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
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
> 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
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
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
> 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
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
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
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:
>
>
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
nks 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_maintenanc
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
>
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:
(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 somewh
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
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
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 modules?
&g
(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
>
> 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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
> > 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
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
> 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
> > 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
> > 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
> 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
> 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
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?
> 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
> 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
> > 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
> 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"
> 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
> 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,
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:
>
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
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
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
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 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
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
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
> 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
--
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,
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
>
> 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
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
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
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
> 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
>> 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
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
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
>
> 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.
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
> 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
>
> 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
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
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
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
1 - 100 of 151 matches
Mail list logo
