Hi all,
wanted to follow up to @thepudds summary below.
I work with multiple modules. For me, I have found the following helpful
1. keeping dependencies acyclic
2. organising the granularity of what is the smallest module to be as
coarse as possible, so there aren't too many modules and
rel
Hi all,
Also, for reference, here are three other related issues:
#26640 "cmd/go: allow go.mod.local to contain replace/exclude lines"
https://github.com/golang/go/issues/26640
#26377 "proposal: cmd/go: module semantics in $GOPATH/src"
https://github.com/golang/go/issues/26377
#2754
Seth and/or Mirko,
What would you think about one of you opening a new issue that covers the
possible approach you were outlining earlier in this thread:
"Another idea is to have a sort of "publish local" semantics, where the
go tool has support for something like -devel tags, which override
Hi all,
This thread is hitting on a fairly important set of topics.
It certainly seems some additional brainstorming and community discussion
about how things could or should work regarding multi-module workspaces
would be beneficial.
A file tree with a `go.mod` has been described as something
And here we have the problem. Low probability of error events do not
scale.
On Fri, 2018-08-31 at 19:30 -0700, Jim wrote:
> Changes from the master/development go.mod will need to be carefully
> merged
> into release go.mod.
--
You received this message because you are subscribed to the Google
I would suggest that developers get used to using one or more separate
branch for releases. Periodically, master will be merged into these
branches as part of the release process.
It's likely that the source for your package (including go.mod) won't be
the only thing that's different between th
Publishing to the local cache is how Maven, a build tool for Java, does it.
There is the concept of snapshot versions. For Golang maybe stating master (or
any other branch) as version would be fitting. Then your CI could use a master
checkout as well.
Regards Mirko
--
You received this messag
On Fri, 31 Aug 2018 10:54:43 -0700 (PDT)
Seth Hoenig wrote:
> On Friday, August 31, 2018 at 12:22:28 PM UTC-5, Victor wrote:
> >
> > Hello everyone. I'm looking for best practices on how to setup your
> > development environment using Go modules.
> >
> > Let assume a situation when you work on a
`go.mod.local` was one idea. Another idea is to have a sort of "publish
local" semantics, where the go tool has support for something like
-devel tags, which override the defined in go.mod. So
then you would "publish" the next version to your local mod cache (just
creating/updating the module
On Sat, 01 Sep 2018 06:57:21 +0930
Dan Kortschak wrote:
> While this seems to be the correct way to do it, it also seems like a
> very obvious point of entry for human error.
Looks like we need `go.mod.local`
ASAP.
In many workplaces a mishap leak of internal paths to the outside, even with
op
While this seems to be the correct way to do it, it also seems like a
very obvious point of entry for human error.
We have tooling to prevent incorrect commits of files using gitignore
and hgingnore and yet people still accidentally commit files that
should not end up in repositories. Now the situ
Seth, thanks! It looks great but what about production vs development
builds? I assume I can add that line to my go.mod when I develop it on my
Mac, but can I reuse the same go.mod file when I do a production build ?
Certainly during a production build I would like NOT to use "replace". Or
shou
On Friday, August 31, 2018 at 12:22:28 PM UTC-5, Victor wrote:
>
> Hello everyone. I'm looking for best practices on how to setup your
> development environment using Go modules.
>
> Let assume a situation when you work on a project where you write a go
> package (call it Pkg) and an applicatio
13 matches
Mail list logo
