So here is the situation:
I have a fork of go-ipfs. It depends on go-ipfs-config. I need to modify go-ipfs-config and make go-ipfs depend on my modified version.
I forked the go-ipfs-config made my changes and made sure to update the path to be that of my forked version as can be seen here. I confirmed that this still builds successfully by running go build
Then I updated go.mod in go-ipfs to use my modified version. I used the replace directive to signify this intention which can be seen here
This is where things gets absolutely bunkers and I am no longer sure what is going on.
When i do go mod tidy to fetch the dependency i get the following output:
go: finding module for package github.com/dadepo/go-ipfs-config
go: found github.com/dadepo/go-ipfs-config in github.com/dadepo/go-ipfs-config v0.5.3
The crazy thing is that v0.5.3 does not exist in github.com/dadepo/go-ipfs-config!
Also the following line get added to go.mod :
github.com/dadepo/go-ipfs-config v0.5.3 // indirect
Which can even be seen here
I have run commands like go clean -modcache and go clean -r etc but does not seem to fix things!
Does anybody know what I am doing wrong? And also how to achieve the goal of making my version of a project depend on another modified version of its dependency?
Ok, so this is as a result of me not being aware of couple of things going on in the Go lang toolchain.
Apparently https://proxy.golang.org is a thing! It is a service operated by google that caches modules. So If you made a release, deleted it, chances are that the version is already cached in https://proxy.golang.org. This was exactly what happened in my case. I had made a 0.5.3 release, deleted it, but it is not really gone as the Google cache already got a hold of it.
So in case you are seeing versions that should not exist. This should be the first place you check. This documentation link also sheds some more light on the proxy and how it can be tweaked.
I found this out based on the conversation I had on the issue I opened reporting this behaviour. If you are curious, you can check it out here.
Related
I made a mistake described here. Unfortunately that question is wrongly closed as "duplicate", and the proposed question is actually not same as mime.
Let me rephrase my question in another way: as a module author, how can I remove a module from Go's "sumsdb" so that mistake like described can be fixed.
Original question pasted below for reference.
EDIT: this question was closed by moderator, but it is NOT answered by the given uri, which gives a different error message:
Why does go get fail with "invalid version: unknown revision"?
I'll rephrase my questions:
I removed tag v1.0.0 from a commit, and tagged another commit. Now I found that the repository is not usable anymore. To verify: you may just do the following:
Clone https://github.com/xrfang/hap
cd into the example directory, then run go build .
This problem not only happens on my PC, but on anyone trying to use the above repo.
I wonder if the problem will disappear over time (as cache expires?) or I have to do something? If it will heal itself, I wonder how long is the cache valid time? If not, I would like to know how to fix that. I hope not using things like GOPRIVATE, as this repo is going to be public (open source).
original post:
I write a http argument parsing tool, and put it at github.com/xrfang/hap. The git log is:
* d8cee08 2022-02-14 | implemented http.Handler interface (HEAD -> master, tag: v1.0.0, origin/master, origin/HEAD) [xrfang]
* 171dc29 2022-02-10 | updated go.mod for example [xrfang]
* d2cea3c 2022-02-09 | added example [xrfang]
* 202d959 2022-02-09 | bug fix in error handling [xrfang]
* ... ...
Problem is, previouly, I tagged commit d2cea3c as v1.0.0. Later I found it not optimal and added some new code. The new code is NOT compatible with v1.0.0, so I should make it v2.0.0. However, as this tool is newly written and I am the only user. I think it is stupid to make it v2.0.0. So I just removed and retagged v1.0.0 to the latest commit d8cee08.
The problem is, go complained that the version is not "authentic". I then removed go.sum, and did go clean -modcache, go get -u, go mod tidy, to no avail. The last try is:
$ go get -u
# example
./main.go:30:11: at.Init undefined (type apiTest has no field or method Init)
./main.go:39:2: undefined: hap.Register
My questions are:
How does Go manage its repository? I previously found that after I updated my module and push it to github, the example often fail to compile, unless I use replace in go.mod, or just wait for a while (e.g. 30 minute). It seems that there is a central "look up table" which is updated periodically and hence oftem lags behind while modules update?
How to fix my current problem of a re-tagged version?
Your understanding is correct as also described in the question you linked.
Either
Publish v2.0.0
Live with GOPRIVATE
Publish v1.1.0
My go version is 1.16, local OS is Windows.
I need to use gorose package. When I use the command
go get -u github.com/gohouse/gorose/v2at goland terminal, it shows
go get: github.com/gohouse/gorose/v2#none updating to
github.com/gohouse/gorose/v2#v2.1.10 requires
github.com/gohouse/golib#v0.0.0-20200727025018-43fec7d17e79 requires
github.com/gohouse/e#v0.0.3-rc.0.20200724104652-25ebf8c9c305: invalid pseudo-version: preceding tag (v0.0.3-rc) not found
Anyone can give me a method to solve this problem, thanks.
It appears that github.com/gohouse/e has removed the v0.0.3-rc tag from their repository, so the pseudo-version based on that tag is no longer valid. (Go modules have a strong expectation that maintainers do not delete tags that have already been published.)
One way to work around this problem is to exclude the invalid version, which will cause dependencies on it to be ignored within your module. To do that, add this line to your go.mod file:
exclude github.com/gohouse/e v0.0.3-rc.0.20200724104652-25ebf8c9c305
Then when you go get github.com/gohouse/gorose/v2 it will re-resolve any missing dependencies on package github.com/gohouse/e using the current latest version of that module.
Another way to work around this problem is to obtain a cached copy of v0.0.3-rc.0.20200724104652-25ebf8c9c305 from a Go module proxy. It appears that that version may be cached by proxy.golang.org, which you can use by setting GOPROXY to proxy.golang.org,direct (or unsetting it entirely, since that's the default for most distributions of the go command) in your environment.
If you have set GOPRIVATE and/or GONOPROXY, you may also need to adjust those variables to ensure that they are not bypassing the proxy for github.com/gohouse/e.
Finally, the ideal long-term solution is to fix these dependencies upstream, so that the module dependency graph includes only valid versions to begin with. You could:
file an issue against the github.com/gohouse/e module requesting that they restore the deleted tags, or
send a PR to github.com/gohouse/golib to update the requirement in their go.mod file to a version that is still valid, then send a PR to github.com/gohouse/gorose to update its dependency on golib to the version containing the fix.
I'm trying to go get go.etcd.io/etcd/tools/benchmark.
Previously this has worked, flawlessly. However when I try to do it currently I have alternatively got no errors and I've had it fail on me with:
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/balancer_conn_wrappers.go:28:2: use of internal package google.golang.org/grpc/internal/buffer not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:49:2: use of internal package google.golang.org/grpc/internal/resolver/dns not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:50:2: use of internal package google.golang.org/grpc/internal/resolver/passthrough not allowed
The first time I ran it on a new go-1.13 installation it worked, but the following times it has failed as above.
The repo has not changed as far as I can tell in the past 8 months and I've tried on various golang versions but all so far have failed (bar the go-1.13 on that first try...).
Any assistance debugging this would be greatly appreciated!
I have both a workaround and an official fix.
The workaround:
Here I defined a go.mod which then used a previous version of the library.
The official fix:
This was fixed upstream and thus no one else should experience this.
I guess you can try by removing vendor folder from the go.etcd.io/etcd repo. Also disable the vendoring mode. It should work.
I'm kinda new to using composer (but I think it is awesome) so please pardon the noob question.
Folks are requesting exports fancier than csv so I thought I'd install phpOffice excel using composer. But, the master is 'build failing' and the develop is 'build error'. An I correct in assuming the master build failed means I should not install this with composer because it won't work?
In researching this I also found phpOffice spreadsheet, but that appears to be in development still.
Any other alternatives if I cannot use phpOffice excel due to the build status issue?
Regardless of what package you are talking about, if the builds for any of the branches are failing it just means that the builds for any of the branches are failing, that's it.
The master and develop branches may be well ahead of the latest tag, and chances are the maintainers are experimenting with it, and working towards a passing build again.
If you trust the maintainers not to release broken software, then it's safe to use one of the tagged versions, so for example, run
$ composer require phpoffice/phpexcel:^1.8.1
to install the latest stable version.
Note It appears that phpoffice/phpexcel:1.8.1 has been released on 2015-05-01; quite some time has passed since. Whether or not this package works for you, then, is something you have to find out for yourself.
For reference, see:
https://packagist.org/packages/phpoffice/phpexcel
I've been trying to modify an addon to accept filtering in custom datalists.
The addon is called DatalistExtensions for Alfresco Share and can be found at https://github.com/deas/contentreich-alfresco-datalists This is supposed to be working on the version 5.*
It comes with an example. That example doesn't work at all, it gives multiple errors... I fixed the errors but it still doesn't work.
The full explanation of the behaviour can be found here:
https://forums.alfresco.com/forum/developer-discussions/alfresco-share-development/filters-custom-datalists-07052016-1320
Now the problem:
I decided to modify the add-on itself. My test was easy, I found where the filter form is created which is inside the file: contentreich-extdl.xml that is found on contentreich-alfresco-datalists-master/contentreich-extdl-share/src/main/resources/alfresco/site-data/extension/
It didn't work at all... Since it was too strange to me I decided to delete one of the built-in filters and it was still working as always which just killed my mind.
The steps I did:
Added the lines into the file.
Ran the mvn package after the change.
Copied the target files created.
What am I missing to make this changes work?
It seems that the changes I was doing were not reflected, in order to archive that you must first clean your maven target and then build the package.
mvn clean
mvn package
or even
mvn clean package
Hope this helps other people!