[go-nuts] go get not downloading a module under a repository from BitBucket
In my git repo (bitbucket.org) I have reponame/ .git/ integration1/ integration2/ integration-common/ └── util ├── go.mod └── readascii.go The module directory is a subdirectory of the git repository. The repository is tagged with v0.0.1. Heres the go.mod module bitbucket.org/orgname/reponame/integration-common/util go 1.14 When I do a go get for this module I get the following error: go get bitbucket.org/orgname/reponame/integration-common/util@v0.0.1 go: downloading bitbucket.org/orgname/reponame v0.0.1 go get bitbucket.org/orgname/reponame/integration-common/util@v0.0.1: module bitbucket.org/orgname/reponame@v0.0.1 found, but does not contain package bitbucket.org/orgname/reponame/integration-common/util I can see the integration-common/util/ directory in bitbucket under the tag v0.0.1 if I look with the web browser. The go.mod has the contents shown above. What is even more odd is that go get does manage to download the other directories in the repository (integration1 and integration2). For some reason it thinks v0.0.1 doesn't contain the integration-common/ directory, even though bitbucket shows it there for that tag. I have to use ssh instead of https because our private repos on bitbucket.org require 2fa. I have this in my ~/.gitconfig: url "g...@bitbucket.org:"]insteadOf = https://bitbucket.org/ I know bitbucket is weird when it comes to using go get. Is there something I missed, or is the a bug with go get and bitbucket? -- 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/2f187538-b2c5-40a2-b574-6d4dbc16a134n%40googlegroups.com.
Re: [go-nuts] Stop triggering firewall on Windows? Preset build path?
If you use `127.0.0.1:0` as your listening address then the firewall won't trigger as well. On Saturday, 7 November 2020 at 15:20:06 UTC+2 Aleistar Markóczy wrote: > I may not be "using go run as a development tool" (which I would deem a > perfectly fine reason to use "go run", I mean what else would you use it > for, maybe to run on production? ;-) ) but the same happens when running go > test to run tests while creating a server to run the tests on. > > The trick of opening the port works perfectly file, thanks! Just open the > windows Firewall Settings > Advanced Settings > Inbound Rules > New Rule > > By Port. > > On Wednesday, 11 February 2015 at 15:38:53 UTC+1 ni...@craig-wood.com > wrote: > >> On 11/02/15 10:13, Mateusz Czapliński wrote: >> > Or, I believe "go build && myappname.exe" (as mentioned by Egon too) is >> > on par with go install, with the small difference between the two (i.e. >> > location of the resulting executable) left up to personal >> > choice/preference/needs. >> >> If you have a big project you'll notice the difference in speed between >> go build and go install. It is especially noticeable if you have >> modified code in a package which you are not typing go build for - that >> has to be rebuilt every time. >> >> In my 25,000 line project split over 50+ files it takes about 2 seconds >> for a cold build, but only 0.6s for a go install after that cold build. >> go install speeds up subsequent go builds. >> >> .../src/github.com/ncw/myproject$ rm -rf >> ~/go/pkg/linux_amd64/github.com/ncw/myproject >> .../src/github.com/ncw/myproject$ time go build >> >> real 0m1.972s >> user 0m1.796s >> sys 0m0.237s >> >> .../src/github.com/ncw/myproject$ time go build >> >> real 0m2.004s >> user 0m1.797s >> sys 0m0.255s >> >> .../src/github.com/ncw/myproject$ time go install >> >> real 0m1.955s >> user 0m1.809s >> sys 0m0.210s >> >> .../src/github.com/ncw/myproject$ time go install >> >> real 0m0.614s >> user 0m0.531s >> sys 0m0.085s >> >> .../src/github.com/ncw/myproject$ time go build >> >> real 0m0.960s >> user 0m0.864s >> sys 0m0.080s >> >> -- >> Nick Craig-Wood -- http://www.craig-wood.com/nick >> > -- 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/fe36826a-1187-4f26-b030-f208497b8fe5n%40googlegroups.com.
Re: [go-nuts] Go modules replace statements referencing legacy codebases
Hi, I don't fully understand why we have to use replace directives (I'm still learning my way around go modules), but I have tried extensively to remove them and I can't get go mod to honour an acceptable set of versions in the requirement. I am guessing at a few potential reasons why this situation may be; some guesses may be wrong, and I do recognise that the cases are all horrible: 1- There are cases where packages in the imported libraries end in paths like /v1 (but where this predates and has nothing to do with go modules). I don't know if that can confuse the go module version decision logic. 2- There are cases where the package repos have git tags in the form vX.Y.Z which also predate and have nothing to do with go modules. I don't know if that can confuse things either. 3- There are quite potentially errors in the defined package inter-dependencies which are driving the go module decision logic to resolve to use versions which are unacceptable to me; I have no idea. 4- There are also cases (I tried to omit this in my original mail in an attempt to simplify) where an imported package is a fork where the original package has gone away (e.g. bitbucket.org/ww/goautoneg) or where a genuine fork has been made but neither the fork nor the code that imports it has yet been updated with the new import paths. All of this is pretty disgusting, but it's also completely outside my control to get fixed quickly. I think it's a real world example of complexities and technical debt involved in a large scale system involving multiple separate teams which are themselves trying to migrate to go modules and whose release timescales slow down getting fixes out of the door (oh, for a monorepo!). I guess I'm trying to work out the least worst way of working around this sort of thing as a lowly package importer. Cheers, Jim -- 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/eb6927f7-5915-ac11-d7ac-1dbaa03b1630%40minter.uk.
Re: [go-nuts] Stop triggering firewall on Windows? Preset build path?
I may not be "using go run as a development tool" (which I would deem a perfectly fine reason to use "go run", I mean what else would you use it for, maybe to run on production? ;-) ) but the same happens when running go test to run tests while creating a server to run the tests on. The trick of opening the port works perfectly file, thanks! Just open the windows Firewall Settings > Advanced Settings > Inbound Rules > New Rule > By Port. On Wednesday, 11 February 2015 at 15:38:53 UTC+1 ni...@craig-wood.com wrote: > On 11/02/15 10:13, Mateusz Czapliński wrote: > > Or, I believe "go build && myappname.exe" (as mentioned by Egon too) is > > on par with go install, with the small difference between the two (i.e. > > location of the resulting executable) left up to personal > > choice/preference/needs. > > If you have a big project you'll notice the difference in speed between > go build and go install. It is especially noticeable if you have > modified code in a package which you are not typing go build for - that > has to be rebuilt every time. > > In my 25,000 line project split over 50+ files it takes about 2 seconds > for a cold build, but only 0.6s for a go install after that cold build. > go install speeds up subsequent go builds. > > .../src/github.com/ncw/myproject$ rm -rf > ~/go/pkg/linux_amd64/github.com/ncw/myproject > .../src/github.com/ncw/myproject$ time go build > > real 0m1.972s > user 0m1.796s > sys 0m0.237s > > .../src/github.com/ncw/myproject$ time go build > > real 0m2.004s > user 0m1.797s > sys 0m0.255s > > .../src/github.com/ncw/myproject$ time go install > > real 0m1.955s > user 0m1.809s > sys 0m0.210s > > .../src/github.com/ncw/myproject$ time go install > > real 0m0.614s > user 0m0.531s > sys 0m0.085s > > .../src/github.com/ncw/myproject$ time go build > > real 0m0.960s > user 0m0.864s > sys 0m0.080s > > -- > Nick Craig-Wood -- http://www.craig-wood.com/nick > -- 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/60247472-ac88-402e-a501-4eeb8b6c6ecan%40googlegroups.com.
Re: [go-nuts] Go modules replace statements referencing legacy codebases
I don't quite understand why you're using replace directives here rather than just declaring the pseudo-version as a requirement. Why wouldn't that work? On Fri, 6 Nov 2020, 14:19 Jim Minter, wrote: > Hi, > > Using Go 1.14, I'm working on a parent codebase which, in its go.mod > file, has a number of replace statements referencing legacy child > codebases which have not yet converted to Go modules. > > At this stage the legacy child codebases handle versioning by branch, > rather than using semantic versioning, so my go.mod file has a number of > statements like these: > > > replace github.com/foo/bar => github.com/foo/bar > v0.0.0-2020xx- // should track branch baz > > replace github.com/foo/bar1 => github.com/foo/bar1 > v0.0.0-2020yy- // should track branch baz > > My goal is to be confident that if I update dependencies in the parent > codebase (go get -u ./...), I'll be pulling in HEAD on the relevant > branch of all the legacy child dependencies. > > My expectation is that this is a transitional use case because > eventually the child codebases will migrate to Go modules, but until > then, it's important to me to know I will pull in critical fixes from > the child dependencies if they happen. > > The difficulty I've got is ensuring that the replace stanzas are valid > and up-to-date. I'm not finding a great way to do this with the Go > module tooling and I wonder if I'm missing anything. Here are the > feasible ugly alternatives I've found so far: > > 1. Child by child, abuse the fact that `go mod tidy` rightly or wrongly > seems to tolerate a single legacy branch reference in the file at a time > and rewrites it to the v0.0.0-2020xx- format: > > > go mod edit -replace github.com/foo/bar=github.com/foo/bar@baz > > go mod tidy > > go mod edit -replace github.com/foo/bar1=github.com/foo/bar1@baz > > go mod tidy > > ...etc... > > go get -u ./... > > 2. A script to be run manually (or via go generate? yikes!) before > running go get -u ./..., containing abominations like this: > > > go mod edit -replace github.com/foo/bar=$(go list -mod=mod -m > github.com/foo/bar@baz | sed -e 's/ /@/') > > go mod edit -replace github.com/foo/bar1=$(go list -mod=mod -m > github.com/foo/bar1@baz | sed -e 's/ /@/') > > ...etc... > > go get -u ./... > > 3. Alternative abominations like this: > > > go mod edit -replace github.com/foo/bar=github.com/foo/bar $(curl -s > https://proxy.golang.org/github.com/foo/bar/@v/baz.info | jq -r .Version) > > go mod edit -replace github.com/foo/bar1=github.com/foo/bar1 $(curl -s > https://proxy.golang.org/github.com/foo/bar1/@v/baz.info | jq -r .Version) > > ...etc... > > go get -u ./... > > I'm wondering: is there a better way? Should there be? > > Many thanks! > > Jim Minter > > -- > 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/922448f0-00cf-7f7e-efdc-50965aefc6d4%40minter.uk > . > -- 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/CAJhgach1cXDw%2BiLM0w%2BerOOcURpKQv%2BcDUbw6qSSYUMpfdSQ1A%40mail.gmail.com.
