I have two local git repositories. Both are go modules. Call them,
foo.com/one and foo.com/two. Both have go.mod files declaring
themselves to be, respectively, foo.com/one and foo.com/two based on go
1.15.
I want to use a package from one in the other.
import "foo.com/one/pkg/thing1"
On 8/17/20 08:41, fge...@gmail.com wrote:
On 8/17/20, 'K Richard Pixley' via golang-nuts
wrote:
On 8/15/20 00:43, fge...@gmail.com wrote:
On 8/15/20, Marvin Renich wrote:
* Volker Dobler [200814 14:53]:
On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
Isn't
On 8/15/20 00:43, fge...@gmail.com wrote:
On 8/15/20, Marvin Renich wrote:
* Volker Dobler [200814 14:53]:
On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
Isn't this the default location? I just untarred the distribution...
No. There is a reason
On 8/14/20 11:54, 'Carla Pfaff' via golang-nuts wrote:
People and installers usually install Go in /usr/local/go on Unix-like
systems.
~/go is the default GOPATH if not set, so ~/go/bin is where binaries
installed via "go get" / "go install" land. But the Go distribution
itself must not be
On 8/14/20 11:27, 'Carla Pfaff' via golang-nuts wrote:
This has nothing to do with modules. You're still using the old GOPATH
mode, because you're not in a directory with a go.mod file. GOPATH
defaults to $HOME/go when it's not set (since 1.8), but that's where
you chose to put your Go
On 8/14/20 11:20, Jan Mercl wrote:
[External Email. Be cautious of content]
On Fri, Aug 14, 2020 at 8:03 PM 'K Richard Pixley' via golang-nuts
wrote:
What am I missing?
package github.com/mna/pigeon: cannot download, $GOPATH must not be set to
$GOROOT. For more details see: 'go help gopath
I'm consistently finding modules confusing.
Here's today's confusion. I /think/ I've eliminated local environment
settings but, once done, go get isn't working and I don't understand
what needs to be changed. What am I missing?
kpixley@editsb> type go
-bash: type: go: not found
-gk!SlX7HXyBDsi3JH4W9wJK6Fot9ltqulcQ3vK1SsKXdK8vOv8IKWkfnlQMBFNMg5X6-w$>
On Tue, Jul 28, 2020 at 8:35 PM 'K Richard Pixley' via golang-nuts
mailto:golang-nuts@googlegroups.com>>
wrote:
I'm currently working with pigeon, a peg based parser generator.
When I...
* make a go error in the source file,
I'm currently working with pigeon, a peg based parser generator.
When I...
* make a go error in the source file, grammar.peg...
* that is processed correctly by pigeon into an invalid grammar.go...
* and the go compiler correctly complains about the error...
* it complains about an error in
Thank you!
I hadn't run into any references to that one in any of the doc.
On 7/21/20 23:56, Amnon wrote:
[External Email. Be cautious of content]
GOPRIVATE is your friend.
https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules
I'm think I understand the go-1.14 downloadable module workflow. But I'm
not getting how to use modules in an enterprise system where we cannot
allow automated downloads or where I want to include packages from one
local module in another where neither are available on any public
download
I generally do the reverse.
Everything is internal, lower case, until and unless I need it
elsewhere. Then I reevaluate where the boundaries should be at that time.
I often find that as an exported API, I need/want different things out
of it than I did when it was internal.
--
You
Bah. No, of course not. Never use it.
Thank you.
On 6/19/20 12:37 AM, Brian Candler wrote:
~/go/bin is not in your $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
I must be missing something. Could someone please point me?
kpixley@kpixley-mbp> go version
go version go1.14.4 darwin/amd64
kpixley@kpixley-mbp> go get golang.org/dl/go1.14.4
kpixley@kpixley-mbp> type go1.14.4
bash: type: go1.14.4: not found
kpixley@kpixley-mbp> go get golang.org/dl/go1.13.12
On 6/16/20 5:00 AM, Russ Cox wrote:
...I will quote from the Code of Conduct here – “regardless of gender
identity and expression, sexual orientation, disabilities,
neurodiversity, physical appearance, body size, ethnicity,
nationality, race, age, religion, or similar personal
If they end up "littering", then I'll agree. So far, I just need the
one... hold my beer...
On 4/13/20 10:40 AM, Robert Engels wrote:
I don’t think littering your code with state variable and branches
just to test is in anyway a good (or sustainable approach) approach.
I have never seen any
On 4/10/20 4:15 PM, Ian Lance Taylor wrote:
I'm not proud. Here is an example program for which os.Open(dirname)
succeeds but ioutil.ReadDir(dirname) fails. You may have to adjust
pathMax and nameMax for your system. Whether you actually want to use
this technique is left to you.
Thank you.
I like this solution better than Ian's, thank you.
If I can't eliminate an error, or fake it, add a new one. :).
On 4/12/20 4:04 PM, Rob Pike wrote:
I am the author of the test coverage tool, and I do not believe that
100% code coverage is the right goal. Coverage is a proxy for testing
On 4/12/20 6:55 AM, Kevin Malachowski wrote:
[External Email. Be cautious of content]
Is there a particular reason you want 100% code coverage?
In this case, I'm writing code that will be the introduction of go to a
team of which I am now a fresh member. 100% code coverage opens eyes.
I have some code. It uses ioutil.ReadDir which returns a possible error.
My testing is at 99% code coverage because I can't figure out a way to
set up a situation in which os.Open succeeds on a directory, but
ioutil.ReadDir fails.
I can get to 100% code coverage if I throw away the err
20 matches
Mail list logo
