Rename of Sirupsen -> sirupsen caused glide to fail

[dobegor]

This rename caused glide get and glide update fail because some packages import github.com/Sirupsen/logrus (most packages) and some github.com/sirupsen/logrus.

Could you please revert this?

In future, I suggest you to move logrus in organization account.

[dobegor]

I.e. Masterminds/glide#863

[dobegor]

While I studied the complete history of this (renaming, reverting, then renaming again), I wonder what the hell on Earth would make a developer to do this. I do understand that employee enforce some standard on naming, but it was a long time ago people suggested moving logrus to an organization account and author dismissed it.

Instead of apologies in the README it would make more sense to think out all available consequences of such decision and compare them with the benefit. It not only hurt those projects which didn't use vendoring: many vendored libraries depend on lowercases import and it caused multiple problems with different package managers, especially on case-insensitive systems (God, it was such a mess).

[sirupsen]

@dobegor this was a failure of a decision, not enough care was taken. I absolutely agree. The only real answer I can give you is that sufficient thought was not put into it, due to many other personal obligations. Clearly, if all this information has been in front of me, I would not have pushed forward.

To improve this going forward, I am looking for maintainers for this project and have already engaged with some who are interested in maintaining it. They will be able to make better decisions than I on this project. I do not work with Go often enough anymore, which is at the end of the day is the root of this failure.

Please see #570 (comment) for the most elaborate comment on this matter.

[dmathieu]

You can fix glide as explained here: #553 (comment)
Closing this issue.

[dobegor]

@dmathieu I mentioned that fix won't help if you are running glide on case-insensitive filesystems.
Reopen this issue, please.

[dmathieu]

You can fix this on case-insensitive filesystems fairly easily.

• Entirely delete the vendorized Sirupsen/logrus package.
• Check that into GIT (no need to commit. You just need to git add).
• Rename all occurences of the package name.
• Fetch the package again, with the name lowercased.
• Check everything back into GIT.

The rename back into Sirupsen is not something that will happen. Removing the dependency from the project and adding it back lower-cased is the only way you can get it working again.

[dobegor]

The problem is there are many third-party dependencies that weren't updated that depend on Sirupsen/logrus and didn't vendor it. "Dependency hell is NP hard" (c) rsc.

[nickhudkins]

It's very easy to fix. Reformat as a case sensitive file system. Do you ever want to deal with it again? Protect yourself. You are a dev, you work with tooling built for unix (and case sensitivity is a thing) so..... adjust accordingly.

…

On Tue, Jul 11, 2017 at 5:18 PM George Dobrovolsky ***@***.***> wrote: The problem is there are many third-party dependencies that weren't updated that depend on Sirupsen/logrus and didn't vendor it. "Dependency hell is NP hard" (c) rsc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#566 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASQdvQpDEj457shW4hpFoeJhRU1YIP7ks5sM-ajgaJpZM4ONYOo> .

[dobegor]

@nickhudkins
Case sensitivity is part of a filesystem, not a UNIX standard/convention etc.

Also, one of the most popular dev OS - macOS - is case insensitive by default.

[nickhudkins]

Yes, and you too (as a macOS user) can have a case sensitive file system. The default behavior of macOS is not behavior designed for developers. There is a solution, that does not require forking of all libraries, that allow your development machine to be far more similar to your deployment target. Sounds like a solid plan to me. Thank you for your correction as to my mis-representation of case sensitivity being a unix standard.

…

On Tue, Jul 11, 2017 at 7:09 PM George Dobrovolsky ***@***.***> wrote: @nickhudkins <https://github.com/nickhudkins> Case sensitivity is part of a filesystem, not a UNIX standard/convention etc. Also, one of the most popular dev OS - macOS - is case insensitive by default. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#566 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASQdoCD56EUAw2SFE3RvQ9ZK1tI1_G-ks5sNACcgaJpZM4ONYOo> .

[nickhudkins]

I offered a solution to the issue. I also provided reason for why one might want to chose the solution I offered. The goal of which, was providing help to those struggling to find a solution. If you have another solution, I'm sure other watchers of this issue, along with related issues, would be forever grateful.

…

On Tue, Jul 11, 2017 at 7:14 PM Nick Hudkins ***@***.***> wrote: Yes, and you too (as a macOS user) can have a case sensitive file system. The default behavior of macOS is not behavior designed for developers. There is a solution, that does not require forking of all libraries, that allow your development machine to be far more similar to your deployment target. Sounds like a solid plan to me. Thank you for your correction as to my mis-representation of case sensitivity being a unix standard. On Tue, Jul 11, 2017 at 7:09 PM George Dobrovolsky < ***@***.***> wrote: > @nickhudkins <https://github.com/nickhudkins> > Case sensitivity is part of a filesystem, not a UNIX standard/convention > etc. > > Also, one of the most popular dev OS - macOS - is case insensitive by > default. > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#566 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AASQdoCD56EUAw2SFE3RvQ9ZK1tI1_G-ks5sNACcgaJpZM4ONYOo> > . >

[sjansen]

For the benefit of anyone brought here by Google...

solution: #553 (comment)
reason: #570 (comment)