choir: remove Gorilla Toolkit dependencies

[cyberious]

Description

Gorilla Toolkit has been sunset and the repo is in Archive mode only, unfortunately, they were unable to find maintainers of the library. As such, bug and security fixes will not be coming, I believe it is time to plan a path forward to replace this dependency. It will be no small undertaking but should be done and the planning should start sooner rather than later.

Additional Information

No response

[sio4]

Just moved this topic to the discussion (from the issue) since I think it is more likely a topic for here :-)

Here are some of my points (sorry for my poor Yonglish. I hope it is clear but not fully sure):

• I don't think the archived mode means sunset. It is just a kind of solid rock, or the sun just stop moving but is still firing in the West sky.
• I guess there are no or fewer issues to be fixed in those modules because it could be one of the reasons they cannot find new active maintainers who have interests. So I don't worry about their decision of archiving too much.
• If we found any issue that should be fixed in those modules, we can fork them and fix the issue ourselves. The fork is not necessarily to be the official successor, we can cut down or extend them to fit our purpose if it needed, they could be only for us and our users.
• Of course, if we found any shiny new replacement, we could move there but I believe the choice will be made because they are great not by the inactivity of Gorilla.

[sio4]

currently, we use:

• https://github.com/gorilla/mux
• https://github.com/gorilla/sessions
• https://github.com/gorilla/handlers
• https://github.com/gorilla/securecookie (indirectly by gorilla/sessions)
• https://github.com/gorilla/css (indirectly by microcosm-cc/bluemonday)

[Jeeejeets]

Well, in my team we were considering giving Buffalo a shot, but the fact that it depends so heavily on archived gorilla project (and even on more than one repo in it) makes it a poor choice.

Now don't get me wrong, I appreciate all the work that has been put into the Buffalo, the way it looks now and the possibilities it gives. It really is a great job. And I see that replacing such a dependency is no piece of cake. However, the very fact that a dependency, especially this big became archived is a deal breaker for us, and at least a large discouragement for others to use Buffalo in production.
I see your point, that you may always fork the repo and just fix the issues and that there are not much issues there, but since most medium to big companies have their own "tooling filter" which often considers archived dependencies as absolutely unacceptable, it makes the formalities much harder, if not impossible to pass. Even if a software house decides to give it a shot and try it in a project, there's still large chance that the client will just cut it without dwelling into whether Gorilla is good for use anyway or not.

I'm not saying that forking Gorilla, taking over the maintenance of it or even changing the dependency may make Buffalo a popular and good choice to use in production, but maintaining status quo will surely make it hard to achieve.

[paganotoni]

Thanks for putting this one together, @sio4. If we replace Gorilla's libraries, it may be worth building/forking them into our own maintained version to avoid being in the same position in the future. Otherwise, there is always the risk of an open-source repo being archived and having to find an alternative.

[rpwatkins]

FYI: Gorilla repos forked.

[AngeloChecked]

!!! https://www.reddit.com/r/golang/comments/14xyido/the_gorilla_web_toolkit_project_is_being_revived/

[alwindoss]

The Gorilla mux and family of libraries and toolkits have a new set of maintainers. Isn't this good news for the Buffalo ecosystem?

[cyberious]

Yes, but did Buffalo change the copy since it was brought into the codebase?

[cyberious]

With new maintainers, I am going to close the discussion. There should be a new discussion to either continue forked version or revert to community main upstream version.