Ay, a lot of projects are now broken after changing the casing of this project's git repository name. Docker/Moby, for example, can no longer be installed via glide, due to the Sirupsen/logrus 404.
Yes, original rename was a perfect failure.
Any ETA? I was just gliding again and again and again
@elaijuh adding lowercase package and repo to your glide.yaml may fix the problem
- package: github.com/sirupsen/logrus
version: master
- package: github.com/Sirupsen/logrus
repo: https://github.com/sirupsen/logrus.git
version: 10f801ebc38b33738c9d17d50860f484a0988ff5
i was seeing this
[ERROR] Update failed for github.com/sirupsen/logrus: The Remote does not match the VCS endpoint
oh that was glide cache problem though
now glide helps to resolve the dep like this
- package: github.com/sirupsen/logrus
version: master
- package: github.com/Sirupsen/logrus
repo: https://github.com/sirupsen/logrus.git
version: master
@vearutop it won't help if you are running OS with case-insensitive filesystem (macOS by default and Windows are).
See answer here https://github.com/sirupsen/logrus/issues/566#issuecomment-313932685 as well.
I feel powerless, guilty, and deeply ashamed. I have not worked enough with Go in the past few years, and thus this decision was not taken with enough care. This is the root of why this has gone awry. At this point, I am fairly convinced a revert will make things worse. Keep in mind this is _only_ breaking for people with mixed imports. Upper-case continues to work in projects that don't mix case. _Every_ library should use lower-case to avoid this problem.
I am actively engaging now with prospective maintainers who can provide better stewardship of Logrus than I have been able to provide. Before the rename, many people used Logrus with a lower-case import, because it _happened_ to also work. Internally and in the projects I've been engaged with that use Logrus, lower-case imports have dominated. I was swayed by this availability bias. Before making this decision, data should've been gathered for the final direction (force lower-case, or force upper-case) and the other method actively deprecated.
I _do_ know many struggled with the uppercase variant, but it is possible the better course of action would've been to work at workarounds there and kill the lower-case altogether. Of course, those benefitting from the change will _not_ be active here (but I am fairly convinced fewer people benefit from the change, than it negatively affects, thus the regret).
For the record, the original proposal was in this PR: https://github.com/sirupsen/logrus/pull/384.
Note also that it's not the rename of my handle from Sirupsen to sirupsen that's causing issues, but rather the conflicting imports mixing upper- and lower-case. Github sets up a proper redirect. You can still use upper-case imports, you just can't mix them. That's why I originally didn't think this would cause as large issues as it's proved to.
Only people who are importing projects that also use Logrus, where both mix cases are causing issues. This is the vast minority, but those dealing with it鈥擨 understand it's frustrating.
I hope, at least, this will serve a greater lesson to the Go community and never happen again. This was, unfortunately, bound to happen at some point that someone would be careless enough to do what was done here.
I am confident that this project will come out better because of it:
An abbreviated timeline of this issue:
Ugh, we have major issues even when using https://github.com/golang/dep
error while exporting github.com/sirupsen/logrus: /var/folders/hr/5zb8r0yx4sv4_1dc0rlccflm0000gn/T/dep105205437/github.com/sirupsen/logrus/.gitignore already exists, no checkout
...
etc.
I'm on MacOS, which has case-insensitive file system. Well, even git itself has problems renaming the repo :D
EDIT:
I figured it out. For anyone interested (and using https://github.com/golang/dep), I had to:
github.com/Sirupsen/logrus from our codebasegithub.com/Sirupsen/logrus - this includes all the transitive dependencies!rm -rf $GOPATH/pkg/dep cacherm -rf $REPO/vendor/github.com/Sirupsen/logrus@sirupsen Don't feel bad. If Go had a reasonable module system and an official package manager this likely wouldn't have been an issue at all. Most languages just don't have these kinds of issues.
ETA on the rename? Already lost several hrs trying to "migrate" to the lowercase, but no luck so far...
@ledio there won't be any renaming back, see this comment.
Steps to fix your codebase:
rm -rf vendor/github.com/Sirupsen/logrusrm -rf $GOPATH/src/vendor/github.com/Sirupsen/logrus"github.com/Sirupsen/logrus" imports to "github.com/sirupsen/logrus" everywhere in you codebase (verify with git grep "github.com/Sirupsen/logrus")git commit (this is important - git doesn't recognize upper->lower renames on Win/MacOS - you need to remove the directory first and commit it)github.com/sirupsen/logrus vendor dependency using your dependency manager and git add itgit commitGood luck!
@dmathieu in case you never saw this thread- you should read through this and look at the timelines to understand the consequences of breaking import paths and the time it takes for them to fully propagate.
I'm closing this issue. The explanation above should explain why we will not do this.
Thanks for being honest and open with your decision @sirupsen. It's not easy being famous =-)
For my company, we have several projects and helper libs that uses this lib. We updated all the libs and projects from upper to lower. Then remove those projects from the go PATH (they'll just be reimported/downloaded when running go get again) and that solved it.
I too am dealing with fallout from this issue.
I am trying to go (1.13.3) build gitlab.com/msvechla/vaultbeat with GO111MODULE=on
This project does not yet have a go.mod (I am trying to push this frontier)
It's unclear how to fix this.
go: gitlab.com/msvechla/vaultbeat imports
github.com/elastic/beats/libbeat/cmd/instance imports
github.com/elastic/beats/libbeat/autodiscover/providers/docker imports
github.com/elastic/beats/libbeat/common/docker imports
github.com/docker/docker/api imports
github.com/Sirupsen/logrus: github.com/Sirupsen/[email protected]: parsing go.mod:
module declares its path as: github.com/sirupsen/logrus
but was required as: github.com/Sirupsen/logrus
Most helpful comment
See answer here https://github.com/sirupsen/logrus/issues/566#issuecomment-313932685 as well.
I feel powerless, guilty, and deeply ashamed. I have not worked enough with Go in the past few years, and thus this decision was not taken with enough care. This is the root of why this has gone awry. At this point, I am fairly convinced a revert will make things worse. Keep in mind this is _only_ breaking for people with mixed imports. Upper-case continues to work in projects that don't mix case. _Every_ library should use lower-case to avoid this problem.
I am actively engaging now with prospective maintainers who can provide better stewardship of Logrus than I have been able to provide. Before the rename, many people used Logrus with a lower-case import, because it _happened_ to also work. Internally and in the projects I've been engaged with that use Logrus, lower-case imports have dominated. I was swayed by this availability bias. Before making this decision, data should've been gathered for the final direction (force lower-case, or force upper-case) and the other method actively deprecated.
I _do_ know many struggled with the uppercase variant, but it is possible the better course of action would've been to work at workarounds there and kill the lower-case altogether. Of course, those benefitting from the change will _not_ be active here (but I am fairly convinced fewer people benefit from the change, than it negatively affects, thus the regret).
For the record, the original proposal was in this PR: https://github.com/sirupsen/logrus/pull/384.
Note also that it's not the rename of my handle from
Sirupsentosirupsenthat's causing issues, but rather the conflicting imports mixing upper- and lower-case. Github sets up a proper redirect. You can still use upper-case imports, you just can't mix them. That's why I originally didn't think this would cause as large issues as it's proved to.Only people who are importing projects that also use Logrus, where both mix cases are causing issues. This is the vast minority, but those dealing with it鈥擨 understand it's frustrating.
I hope, at least, this will serve a greater lesson to the Go community and never happen again. This was, unfortunately, bound to happen at some point that someone would be careless enough to do what was done here.
I am confident that this project will come out better because of it:
An abbreviated timeline of this issue: