Renaming upper-case 'Sirupsen' to 'sirupsen'

[tobbbles]

The reason for this is that most other packages use lower-case naming conventions.

The vendoring tool I use (GB) is case sensitive, and can become a massive pain in the 🍑 when Logrus is the only package with an upper-case name (as most other packages are in lower case, following https://blog.golang.org/package-names) - this often leads to build failures.

Why don't you just vendor it in lower case?

Because Logrus has itself as an internal dependency, it vendors two folders, Sirupsen/logrus and sirupsen/logrus.

[aarongreenlee]

Thank you for your contribution, @mnzt.

Tools like go get seem to be case insensitive. I wonder if GB would also benefit by becoming case insensitive.

I don't see any negative side effects to this pull request and will accept it as soon as the tests can pass.

Thanks again.

[aarongreenlee]

Thank you for your contribution, @mnzt.

Tools like go get seem to be case insensitive. I wonder if GB would also benefit by becoming case insensitive.

I don't see any negative side effects to this pull request and will accept it as soon as the tests can pass.

Thanks again.

[tobbbles]

@aarongreenlee thank you for taking time to review the PR 😄.

It looks like a linter tool automatically removed the airbrake import, whoops!

I've noticed that logrus examples imports airbreak, which in turn imports logrus - to circumvent this issue I have added a build constraint flag. Hopefully all goes well on the following CI check 😸

[tobbbles]

@aarongreenlee thank you for taking time to review the PR 😄.

It looks like a linter tool automatically removed the airbrake import, whoops!

I've noticed that logrus examples imports airbreak, which in turn imports logrus - to circumvent this issue I have added a build constraint flag. Hopefully all goes well on the following CI check 😸

[glasser]

"constraint"

[glasser]

"constraints"

[glasser]

Does it make sense to use Go 1.4 custom import path checking for this? https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7vYv5hWtPx9--lTx1gPMs/edit

[glasser]

Does it make sense to use Go 1.4 custom import path checking for this? https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7vYv5hWtPx9--lTx1gPMs/edit

[tobbbles]

@glasser I think the main issue here was that an import cycle was created in examples/hook.

[tobbbles]

@glasser I think the main issue here was that an import cycle was created in examples/hook.

[tobbbles]

Any progress on this @aarongreenlee?

[tobbbles]

Any progress on this @aarongreenlee?

[stevvooe]

@sirupsen This looks like a real issue but it would be a possibly breaking change.

Any opinion here?

[stevvooe]

@sirupsen This looks like a real issue but it would be a possibly breaking change.

Any opinion here?

[sirupsen]

How do you think this could break @stevvooe? This just changes the copy/paste examples to use lower-case, right?

[sirupsen]

How do you think this could break @stevvooe? This just changes the copy/paste examples to use lower-case, right?

[stevvooe]

@sirupsen When this package changes to github.com/sirupsen/logrus, won't the builds fail if the only thing found in GOPATH is github.com/Sirupsen/logrus on a case sensitive filesystem?

For the most part, I am not against this change. If we are willing to risk possible breakage, it is for the better.

[stevvooe]

@sirupsen When this package changes to github.com/sirupsen/logrus, won't the builds fail if the only thing found in GOPATH is github.com/Sirupsen/logrus on a case sensitive filesystem?

For the most part, I am not against this change. If we are willing to risk possible breakage, it is for the better.

[tobbbles]

People can still vendor an upper case S in sirupsen, however it's common
practice to keep packages as lower case.

On Fri, 18 Nov 2016, 19:53 Stephen Day, notifications@github.com wrote:

@sirupsen https://github.com/Sirupsen When this package changes to
github.com/sirupsen/logrus, won't the builds fail if the only thing found
in GOPATH is github.com/Sirupsen/logrus on a case sensitive filesystem?

For the most part, I am not against this change. If we are willing to risk
possible breakage, it is for the better.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#384 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJoYeyCn7T3FTfu8oWgjWCFAUr3GT-Rbks5q_gIkgaJpZM4JO2SM
.

[tobbbles]

People can still vendor an upper case S in sirupsen, however it's common
practice to keep packages as lower case.

On Fri, 18 Nov 2016, 19:53 Stephen Day, notifications@github.com wrote:

@sirupsen https://github.com/Sirupsen When this package changes to
github.com/sirupsen/logrus, won't the builds fail if the only thing found
in GOPATH is github.com/Sirupsen/logrus on a case sensitive filesystem?

For the most part, I am not against this change. If we are willing to risk
possible breakage, it is for the better.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#384 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJoYeyCn7T3FTfu8oWgjWCFAUr3GT-Rbks5q_gIkgaJpZM4JO2SM
.

[tobbbles]

The real issue here is other dependencies vendoring with an upper case S.
Often at work I end up with two vendored lots of logrus - as half use the
common practice, and the over half use what's the in the documentation.

On Fri, 18 Nov 2016, 19:54 Toby Archer, tobyjames1234@googlemail.com
wrote:

People can still vendor an upper case S in sirupsen, however it's common
practice to keep packages as lower case.

On Fri, 18 Nov 2016, 19:53 Stephen Day, notifications@github.com wrote:

@sirupsen https://github.com/Sirupsen When this package changes to
github.com/sirupsen/logrus, won't the builds fail if the only thing found
in GOPATH is github.com/Sirupsen/logrus on a case sensitive filesystem?

For the most part, I am not against this change. If we are willing to risk
possible breakage, it is for the better.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#384 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJoYeyCn7T3FTfu8oWgjWCFAUr3GT-Rbks5q_gIkgaJpZM4JO2SM
.

[tobbbles]

The real issue here is other dependencies vendoring with an upper case S.
Often at work I end up with two vendored lots of logrus - as half use the
common practice, and the over half use what's the in the documentation.

On Fri, 18 Nov 2016, 19:54 Toby Archer, tobyjames1234@googlemail.com
wrote:

People can still vendor an upper case S in sirupsen, however it's common
practice to keep packages as lower case.

On Fri, 18 Nov 2016, 19:53 Stephen Day, notifications@github.com wrote:

@sirupsen https://github.com/Sirupsen When this package changes to
github.com/sirupsen/logrus, won't the builds fail if the only thing found
in GOPATH is github.com/Sirupsen/logrus on a case sensitive filesystem?

For the most part, I am not against this change. If we are willing to risk
possible breakage, it is for the better.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#384 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJoYeyCn7T3FTfu8oWgjWCFAUr3GT-Rbks5q_gIkgaJpZM4JO2SM
.

[stevvooe]

LGTM

@mnzt Have you seen any breakage?

@sirupsen If you put your LGTM, I think we should go through with this. We can send out some tweets to let people know.

[stevvooe]

LGTM

@mnzt Have you seen any breakage?

@sirupsen If you put your LGTM, I think we should go through with this. We can send out some tweets to let people know.

[sirupsen]

Let's go ahead with this.

Will it work with this if I rename myself to @sirupsen instead of @sirupsen on Github? It's silly that I have upper-case.

[sirupsen]

Let's go ahead with this.

Will it work with this if I rename myself to @sirupsen instead of @sirupsen on Github? It's silly that I have upper-case.

[stevvooe]

@sirupsen Please, do the honors. I gave up my capital S long ago.

[stevvooe]

@sirupsen Please, do the honors. I gave up my capital S long ago.

[sirupsen]

Just renamed myself 🙈

[sirupsen]

Just renamed myself 🙈

[stevvooe]

💥

[stevvooe]

💥

[ahmetb]

no more the first dependency listed on Godeps.json 💥

[ahmetb]

no more the first dependency listed on Godeps.json 💥

[hilljgo]

Note: this broke our glide dependencies with the following error:

[WARN]	Error updating github.com/sirupsen/logrus: The Remote does not match the VCS endpoint

changing our import from github.com/Sirupsen/logrus to github.com/sirupsen/logrus fixed it

[hilljgo]

Note: this broke our glide dependencies with the following error:

[WARN]	Error updating github.com/sirupsen/logrus: The Remote does not match the VCS endpoint

changing our import from github.com/Sirupsen/logrus to github.com/sirupsen/logrus fixed it

[stevvooe]

@hilljgo Thanks for the report! Seems like a low impact fix.

[stevvooe]

@hilljgo Thanks for the report! Seems like a low impact fix.

[hryx]

I observed the same Glide issue as @hilljgo, but the problem ended up being exponentially more painful when vendoring several projects which also use Logrus.

If using the old name, Glide fails due to a mismatched remote URL. If using the new name, Go fails due to a case-insensitive import collision.

So the only option I've found, until those vendored projects all start using the lowercase s, is to lock to an older version of Logrus and tell Glide the remote URL explicitly:

- package: github.com/Sirupsen/logrus
  version: a437dfd2463eaedbec3dfe443e477d3b0a810b3f
  repo:    https://github.com/sirupsen/logrus

[hryx]

I observed the same Glide issue as @hilljgo, but the problem ended up being exponentially more painful when vendoring several projects which also use Logrus.

If using the old name, Glide fails due to a mismatched remote URL. If using the new name, Go fails due to a case-insensitive import collision.

So the only option I've found, until those vendored projects all start using the lowercase s, is to lock to an older version of Logrus and tell Glide the remote URL explicitly:

- package: github.com/Sirupsen/logrus
  version: a437dfd2463eaedbec3dfe443e477d3b0a810b3f
  repo:    https://github.com/sirupsen/logrus

[bbrks]

Just leaving a comment here for anybody Googling errors.

case-insensitive import collision: "github.com/Sirupsen/logrus" and "github.com/sirupsen/logrus"

The fix is to lowercase all of your import statements for logrus.

One liner recursive find/replace:

find ./ -type f -name "*.go" -exec sed -i -e 's/github.com\/Sirupsen\/logrus/github.com\/sirupsen\/logrus/g' {} \;

Don't forget to run gofmt if your CI pipeline has it as a requirement! Uppercase and lowercase imports will be in a different order.

[bbrks]

Just leaving a comment here for anybody Googling errors.

case-insensitive import collision: "github.com/Sirupsen/logrus" and "github.com/sirupsen/logrus"

The fix is to lowercase all of your import statements for logrus.

One liner recursive find/replace:

find ./ -type f -name "*.go" -exec sed -i -e 's/github.com\/Sirupsen\/logrus/github.com\/sirupsen\/logrus/g' {} \;

Don't forget to run gofmt if your CI pipeline has it as a requirement! Uppercase and lowercase imports will be in a different order.

[tobbbles]

Note on the above @bbrks' comment, for https://getgb.io you'll need to unvendor (gb vendor delete github.com/Sirupsen/logrus) the uppercase named dependency and then vendor the lowercase named dependency (gb vendor fetch github.com/sirupsen/logrus).

There may be a small teething period of getting everything over to the correct naming - but it'll be worth it in the end

[tobbbles]

Note on the above @bbrks' comment, for https://getgb.io you'll need to unvendor (gb vendor delete github.com/Sirupsen/logrus) the uppercase named dependency and then vendor the lowercase named dependency (gb vendor fetch github.com/sirupsen/logrus).

There may be a small teething period of getting everything over to the correct naming - but it'll be worth it in the end

[cstockton]

The import path is valid per the specification, if the tool doesn't work then they should fix it, if your builds don't work, you should fix them. Breaking every users build with the assumption they could simply vendor is .. ugh, very narrow sighted. Many people import libraries which use logrus, and don't control the import declarations of those libraries and are unable to update them. Meaning they are broke until the package maintainers react.

@sirupsen is this going to be reverted?

@mnzt What value was worth it in the end exactly for everyone? From my observation this was to fix YOUR builds failing:

The vendoring tool I use (GB) is case sensitive, and can become a massive pain in the 🍑 when Logrus is the only package with an upper-case name (as most other packages are in lower case, following https://blog.golang.org/package-names) - this often leads to build failures.

You didn't describe HOW your builds failed so perhaps your builds could be fixed. Instead deciding it was enough of a pain in the 🍑 for you .. and the value you received from fixing YOUR builds.. was enough value to justify breaking EVERY LOGRUS users builds (as well as those who have no choice in the matter as they import a library that imports logrus)? Ugh...

[cstockton]

The import path is valid per the specification, if the tool doesn't work then they should fix it, if your builds don't work, you should fix them. Breaking every users build with the assumption they could simply vendor is .. ugh, very narrow sighted. Many people import libraries which use logrus, and don't control the import declarations of those libraries and are unable to update them. Meaning they are broke until the package maintainers react.

@sirupsen is this going to be reverted?

@mnzt What value was worth it in the end exactly for everyone? From my observation this was to fix YOUR builds failing:

The vendoring tool I use (GB) is case sensitive, and can become a massive pain in the 🍑 when Logrus is the only package with an upper-case name (as most other packages are in lower case, following https://blog.golang.org/package-names) - this often leads to build failures.

You didn't describe HOW your builds failed so perhaps your builds could be fixed. Instead deciding it was enough of a pain in the 🍑 for you .. and the value you received from fixing YOUR builds.. was enough value to justify breaking EVERY LOGRUS users builds (as well as those who have no choice in the matter as they import a library that imports logrus)? Ugh...

[sirupsen]

I've needed to revert this. This breaks way too many builds.

#451

[sirupsen]

I've needed to revert this. This breaks way too many builds.

#451

[sirupsen]

If there remains interest in this, we should do this under logrus/logrus.

[sirupsen]

If there remains interest in this, we should do this under logrus/logrus.

[tobbbles]

I believe the underlying issue here is where internal code 'externally' refers to {S,s}irupsen/logrus, rather than a local import, ie: ../../something. This causes issues in the examples folder however, meaning the examples become uncopyable.

A potential solution is to move the examples out of this repo into their own repo, meaning logrus as a package can consist exclusively of local imports - meaning users can vendor/go get via any case they desire.

/cc @sirupsen @stevvooe

[tobbbles]

I believe the underlying issue here is where internal code 'externally' refers to {S,s}irupsen/logrus, rather than a local import, ie: ../../something. This causes issues in the examples folder however, meaning the examples become uncopyable.

A potential solution is to move the examples out of this repo into their own repo, meaning logrus as a package can consist exclusively of local imports - meaning users can vendor/go get via any case they desire.

/cc @sirupsen @stevvooe

[maxmeyer]

@sirupsen Any near plans about moving the repo?

[maxmeyer]

@sirupsen Any near plans about moving the repo?

[nazieb]

@sirupsen Is the plan moving the repo still on? If that's so, considering github.com/logrus is already taken, I suggest using github.com/go-logrus so we can get benefit of using something like gopkg.in

I've registered the org by the way, and will happily transfer it to you if you want.

[nazieb]

@sirupsen Is the plan moving the repo still on? If that's so, considering github.com/logrus is already taken, I suggest using github.com/go-logrus so we can get benefit of using something like gopkg.in

I've registered the org by the way, and will happily transfer it to you if you want.