Logrus: Rename back to Sirupsen/logrus

Created on 6 Jul 2017  路  14Comments  路  Source: sirupsen/logrus

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.

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 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:

  1. There is a clear path forward for which case to use.
  2. This was the nail in the coffin that caused me to take action based on how large Logrus has grown, and that we need a more competent team of maintainers who are actively working with the library. This project is at the point where it needs to be driven by a committee, not an individual. If you'd like to assist in maintaining this project, please reach out to me by email.

An abbreviated timeline of this issue:

  1. https://github.com/sirupsen/logrus/pull/384 proposed
  2. https://github.com/sirupsen/logrus/pull/384 reverted, due to conflicts in community. Handle stayed lower-case, but that's not an issue as upper-case continues to work.
  3. Internal projects were all using lower-case, and I was being pushed to make a decision both by the Logrus community and internally as for casing. I did _not_ gather the appropriate information to make the right call, and simply made the call to proceed with lower-case. I wish that this decision would've been taken at a point in time where I'd had the surplus energy to put into investigating this that it deserved.
  4. Lower-case is adopted in the community, as the decision is made. Due to neglect on my part (due to many other obligations), this proceeded and at this point undoing the change would cause more bad than good. I do believe that Logrus should've been lower-case to begin with, but the ROI on renaming was simply not high enough鈥攁s pointd out by many members of the community.

All 14 comments

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:

  1. There is a clear path forward for which case to use.
  2. This was the nail in the coffin that caused me to take action based on how large Logrus has grown, and that we need a more competent team of maintainers who are actively working with the library. This project is at the point where it needs to be driven by a committee, not an individual. If you'd like to assist in maintaining this project, please reach out to me by email.

An abbreviated timeline of this issue:

  1. https://github.com/sirupsen/logrus/pull/384 proposed
  2. https://github.com/sirupsen/logrus/pull/384 reverted, due to conflicts in community. Handle stayed lower-case, but that's not an issue as upper-case continues to work.
  3. Internal projects were all using lower-case, and I was being pushed to make a decision both by the Logrus community and internally as for casing. I did _not_ gather the appropriate information to make the right call, and simply made the call to proceed with lower-case. I wish that this decision would've been taken at a point in time where I'd had the surplus energy to put into investigating this that it deserved.
  4. Lower-case is adopted in the community, as the decision is made. Due to neglect on my part (due to many other obligations), this proceeded and at this point undoing the change would cause more bad than good. I do believe that Logrus should've been lower-case to begin with, but the ROI on renaming was simply not high enough鈥攁s pointd out by many members of the community.

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:

  • Remove all instances of the github.com/Sirupsen/logrus from our codebase
  • Update/Remove all the dependencies that imported the github.com/Sirupsen/logrus - this includes all the transitive dependencies!
  • Also, I had to rm -rf $GOPATH/pkg/dep cache
    and rm -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/logrus
  • rm -rf $GOPATH/src/vendor/github.com/Sirupsen/logrus
  • Mass rename "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)
  • fetch the new github.com/sirupsen/logrus vendor dependency using your dependency manager and git add it
  • git commit

Good 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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rogierlommers picture rogierlommers  路  5Comments

drewwells picture drewwells  路  3Comments

piotrkowalczuk picture piotrkowalczuk  路  4Comments

SergeiVasilenko picture SergeiVasilenko  路  3Comments

demizer picture demizer  路  4Comments