Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chi v4 #378

Merged
merged 11 commits into from Jan 9, 2019

Conversation

@pkieltyka
Copy link
Member

commented Jan 8, 2019

chi is a pretty minimal library and has been hardened over the years, so v4 won't introduce any big changes other then a few minor things like..

  • chi's Go support will be inline with Go's own support - #366 - therefore, we remove support for Go 1.7 and 1.8, and stop tracking 1.9
  • return 404 for mux with empty routes #362
  • additional check to ensure wildcard is at the end of a url pattern #333
  • middleware: deprecate support for CloseNotifier - #347
  • Optimal Go module handling #302 - some community submissions: #364 #370 #379

:)

@pkieltyka pkieltyka merged commit ff830bc into master Jan 9, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@pkieltyka pkieltyka deleted the v4-dev branch Jan 10, 2019
@SamWhited

This comment has been minimized.

Copy link

commented Jan 10, 2019

Hello,

Chi v4 was released, but it still doesn't have module support. Does this mean modules and the proper import path won't be supported until v5 for compatibility?

@pkieltyka

This comment has been minimized.

Copy link
Member Author

commented Jan 10, 2019

as mentioned in other issue with the same question.. but for others who follow commits + PR history, will repeat answer here..

@SamWhited yea, it would be chi v5 when we support go modules. I don't see this happening for another 6+ months until go 1.13 is available, in hope the go modules is standard and robust for packages. We had hopes to use go modules now, but ran into a bunch of complexity that didn't make sense to put onto chi which literally has zero dependencies to run, lol.

@SamWhited

This comment has been minimized.

Copy link

commented Jan 10, 2019

Thank you for your answer; in my previous question I was told v4. I will find an alternative to chi for my own projects and for our corporate projects and reevaluate when Chi v5 is released. Thanks for all the hard work you've put in here.

If you need any help with module support feel free to ping me; there's really not all that much complexity to deal with and I'd be happy to walk you through it if support in v4 is still an option.

@cristaloleg

This comment has been minimized.

Copy link

commented Jan 10, 2019

I will find an alternative to chi for my own projects

why +incompatible is a problem for you? (just curious).
It's the same version pinning AFAIK. Am I missing something?

@pkieltyka

This comment has been minimized.

Copy link
Member Author

commented Jan 10, 2019

@SamWhited good luck!

@SamWhited

This comment has been minimized.

Copy link

commented Jan 10, 2019

We have several tools in the same codebase that may not all be updated at once. Without the import compatibility rule we have to update them all at the same time to a single version of Chi instead of having one import chi and one import chi/v4, for example. TL;DR — Modules make incremental updates much easier.

@cristaloleg

This comment has been minimized.

Copy link

commented Jan 10, 2019

What about forking chi (adding Go modules which is trivial) and using replace keyword in go.mod to use the fork?

(probably this is out of scope of this issue)

@SamWhited

This comment has been minimized.

Copy link

commented Jan 10, 2019

I suspect it will be more overhead to maintain a fork than to just find another router that supports modules, but it's a fair point, we'll have to evaluate both options.

@SamWhited

This comment has been minimized.

Copy link

commented Jan 10, 2019

@pkieltyka I meant to say: I don't want to ask you for more work, but if you'd be willing to discuss or write up your thoughts on why modules were hard to implement I'm sure the Go team would really appreciate it. You could stick it on the https://github.com/golang/go/wiki/ExperienceReports page, or submit an issue and I can get it in the right hands and make sure it's seen.

@VojtechVitek

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@SamWhited Well, Go modules were not "hard" to implement. See the working prototype for v4.0.0-rc1 tag at #379.

However, @pkieltyka didn't like that this release would would be suddenly forcing all the chi users to change the import path to the /v4 suffix everywhere. The worry was about the amount of support tickets this could generate; and also the additional complexity thrown at chi users.

Chi v4 doesn't differ from v3 very much. In fact, it's backward compatible from the API perspective and backward compatible functionally for 99% of use cases too. However, we dropped support for Go 1.7 and Go 1.8 and we consider that a breaking change; and that's why we preferred releasing v4.0 over v3.4.

We have several tools in the same codebase that may not all be updated at once. Without the import compatibility rule we have to update them all at the same time to a single version of Chi instead of having one import chi and one import chi/v4, for example. TL;DR — Modules make incremental updates much easier.

This is a fair point and Go modules would be "technically" the only right choice for you if you really wanted to have both chi v3 and chi v4 side by side in a single codebase. But as I mentioned previously, we didn't really break the API in the v4 release. So, you should be able to update all of your tools at once without any trouble, either if it's a large monorepo, or if it's a bunch of small repos. Please, correct me if I'm wrong.

As Peter mentioned before, the chi router doesn't have any external dependencies. So, technically, we don't need to define any minimal versions in a go.mod file at all. So, I think this is strictly a choice of taste and simplicity, since the +incompatible flag will work just fine for now.

@SamWhited

This comment has been minimized.

Copy link

commented Jan 10, 2019

So, you should be able to update all of your tools at once without any trouble, either if it's a large monorepo, or if it's a bunch of small repos. Please, correct me if I'm wrong.

In this case, that is not a risk that we feel is acceptable. I don't know what problems might occur, but that's exactly the point, I don't know. Even if the libraries maintain full API compatibility updating all at once instead of incrementally means there's no time to monitor each component as it comes online for unexpected behavioral changes, panics, or any other bug or minor problem that might have been introduced as part of the upgrade. I'd much rather one service go down than the whole platform.

@VojtechVitek

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2019

@SamWhited That feels like a concern of your deployment strategy rather than of a Go pkg dependency to me.

Anyway, I think you'd have to fork either chi v3 or chi v4 to make a gradual change to your codebase. There's no other way around for now.

@SamWhited

This comment has been minimized.

Copy link

commented Jan 11, 2019

That feels like a concern of your deployment strategy rather than of a Go pkg dependency to me.

That's correct; previously we were performing gradual updates using vendoring and GOPATH hacks. Now that we've updated to Go Modules this is much simpler, but we have two dependencies outstanding; one of which is Chi. I was waiting on v4, but if Modules are not going to be implemented I'm not sure if we can maintain both upgrade paths, but we'll have to experiment and decide if it's less risky to slowly migrate to something else that uses Modules, or maintain a second way of doing incremental upgrades on top of Modules. Any advice you have on doing this with Chi would be welcome.

Anyway, I think you'd have to fork either chi v3 or chi v4 to make a gradual change to your codebase. There's no other way around for now.

Right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.