chi@v1.5.x mod issues #561
Comments
|
Sorry for the trouble -- I realize this is an unusual change, but unfortunately the versioning nuance pre-date go.mod's existence. For dependencies which themselves depend on chi, they will have to be updated to chi@v1.5.1 as well, in order to make use of the new go.mod version -- which is confusing by "numbers", but is the same in either case if a new v5 was released just the same. As for the reasoning to switch back to v1, please see #560. Note, Go 1.16 will include a new feature for go.mod to mark certain versions as "retracted", which should smooth this out and allow you to upgrade then. TBH, there are not many urgent features in chi from v4+incompatible to v1 with go.mod. However, I've had no issues switching to chi v1.5.1 (go.mod) for all of my projects internally. |
|
thx, I just read the discussion in #462 and @zikaeroh summarized it nicely - "v1.5.1 is still semantically lower than any of the +incompatible versions. That's why I'm saying this is going to turn out to not be so fun to handle...". It is indeed not fun and even worse, because in my case an innocent-looking and minor update of the chi module triggered a chain reaction downgrading other dependencies, some of them significantly. I understand you made the call and it is what it is. However, I'd suggest documenting possible risks or at least mention in README how potentially destructive such a Btw, I think if instead of v1.5.x you tag it v5.0.0 it won't break as much as v1.5.x does. I believe v5.0.0 will be considered higher than any of the +incompatible versions by go get, but not 100% sure |
Doing so with a |
Completely agree. I have migrated a dozen libraries from pre-mod to post-mod world with /v2 path change and had no problem with this approach. It feels odd and ugly but works fine and safe |
I agree too. @pkieltyka please release v5 and start from there, please. "Downlograding" to Please reconsider and use UPDATE: As it is it just doesn't work. I'm sorry. Everytime I try to "update" to If I force UPDATE 2: I removed all Golang files from my PC. All go mod cache. Everything! Still the problem. I tried on a new PC with Golang never installed there. Same issue. |
|
hey all, sorry again for these troubles. It upsets me as well to see others having trouble with it. I sure wish go.mod was a thing before chi was created. @frederikhors yes, the downgrading is quite annoying and crazy. However, @zikaeroh helped point out the source of the issue -- which is that in your project if there is a dependency which depends on chi@v3+incompat or chi@v4+incompat, and you try to install chi@v1.5.1, it will assume you're downgrading and then all of those dependencies are arbitrarily downgraded. The only way to resolve this is to ensure that the dependency tree, starting from the deepest package, uses chi@v1.5.1. I've found the best upgrade path for a project:
for gqlgen, I simply ran:
|
|
So I have to contact the author of each project and explain that he has to upgrade a dependency using in fact a downgrade. And that he must be careful before doing so by making sure that each of his dependencies are in turn upgraded to a downgraded version. All this recursively. Can't we use |
|
I love |
|
@frederikhors can you post your dep graph that uses chi? In general, it shouldn't be a child dep of very many packages, nor should be very deep. |
|
I cannot because it's corporate. I'm very sorry about this. And I'm very curious about the new fix for less allocations! |
|
@pkieltyka this is my graph for one of the small services (I have used fake names because this is an internal project) : As you can see even in a small project I have 2 different issues with v1.5.x migration:
To me, both cases look perfectly fine and usual. Updating any other dependency (the one not forcing downgrade) will be trivial, painless, and, most important - relatively safe. Updating chi module is very tricky and extremely scary. If one of my junior developers runs the recommended procedure and not watching go.mod carefully, it could bring back a bunch of old dependencies with various old bugs. In fact, I had to send a group email prohibiting the upgrade of v4.x.x+incompatible due to the potential risks involved. Sure, this is your project and your decision to make, but in my opinion all v.1.5.x idea should be reconsidered one more time |
|
Just to throw in another wrinkle here, we have to fix our version of github.com/99designs/gqlgen to 0.11.3 due to a bug that hasn't been fixed there yet. While we could fork and apply the very nice PR that fixes the bug, and would include chi 1.5.1, we would prefer not to. So that also leaves us unable to upgrade chi on any other packages for now. Not the end of the world, but it hurts to see interlock between dependencies like this, especially when everyone has worked so hard to maintain backward compatibility within major versions. |
|
Here's my report upgrading pretty large project using Go 1.15. $ git diff
modified: go.mod
- github.com/go-chi/chi v4.0.2+incompatible
+ github.com/go-chi/chi v1.5.1
github.com/go-chi/cors v1.1.1
- github.com/go-chi/docgen v1.0.5
+ github.com/go-chi/docgen v1.0.3
github.com/go-chi/jwtauth v3.2.0+incompatible
github.com/go-chi/render v1.0.1
- github.com/mailgun/mailgun-go/v3 v3.5.0This has removed We use $ git diff
modified: go.mod
- github.com/go-chi/chi v4.0.2+incompatible
+ github.com/go-chi/chi v4.0.0+incompatible
github.com/go-chi/cors v1.1.1
- github.com/go-chi/docgen v1.0.5
+ github.com/go-chi/docgen v1.0.3
github.com/go-chi/jwtauth v3.2.0+incompatible
github.com/go-chi/render v1.0.1
- github.com/mailgun/mailgun-go/v3 v3.5.0
+ github.com/mailgun/mailgun-go/v3 v3.6.4And it looks like this actually reverted the new Should the go tool chain prefer I think I hit the same "transitive dependency" issue as the guys above. So, do we really need to fix all these? It feels like there's no silver bullet. It's too bad Go didn't have modules support sooner.
Anyway, I appreciate all the hard work @pkieltyka is doing on this project. ❤️ |
|
@VojtechVitek we all appreciate @pkieltyka's work: Chi is amazing! This is why I insist on |
|
Yes, please, this should be v5. |
|
From what I understand, this might be less of a problem in the future with Go 1.16 and 1.17 Where in 1.16 your internal project can use
Now the more interesting bit will come in Go 1.17 with "lazy loading". more info cmd/go: lazy module loading
None of this makes a difference today though. Was |
|
I have also dependencies in my project which depend on chi: |
|
Another issue with this new version is any automated dependency management tools (i.e. renovate, dependabot, etc...) all want to "upgrade" chi to v4.x.x from v1.5.x since it sees this as semantically lower. |
|
@jones2026, that seems like an issue to file against the automated tools. They should generally be using |
|
@bcmills is that available now or is that coming in release 1.16 for Go? I definitely agree if Go has a way to not pull in deprecated packages and these older versions are marked as such then the tools need to adjust |
|
@jones2026, |
|
Please don't do this. Referring to the PR that introduced this change:
This will be a huge red flag for any serious project maintainer. When a new "minor" version is released, VS Code and Dependabot will ask people to update chi, and then their projects will be broken because the release introduces breaking changes. Or even crazier, they want to update to version 4 and actually perform a downgrade. Such a behavior is a significant reason for replacing chi. The maintainer of Fiber had the same idea, but finally changed their mind: gofiber/fiber#736 (comment) |
|
@bcmills do you know if those go commands will guarantee to return a list of versions in the correct order if semantic versions are not trusted? Or is it only possible to get the |
|
hey all, thanks for the feedback on this issue. It’s unfortunate there are a combination of hiccups — mainly that Go is downgrading other packages unexpectedly, which I agree is a big problem. I do not want to release /v5 and see it on the import path. Rather I’ll probably remove the go.mod support and go back to incompatible mod version tomorrow from v4.x. I hope one day Go’s module support will allow me to control the import path and avoid subscribing to /vX, as the versions are already tracked in source tags and go.sum — the only advantage I see of that format is to support multiple versions of the same package, which id prefer to opt out. Apologies for the annoyance here — I’ll sleep on it, and tomorrow find a better path forward. |
If the retraction system in 1.16 works, then it would alleviate this; I'd almost personally rather things stay as they are and maybe see how that goes (mod file and 1.5, some people can't upgrade) than to switch more than once between not having mod support and having mod support. I can't recall if it'll work, but it'd be interesting if the retract directive could be put in the go.mod now (even though it targets an older version than 1.16), and then see what happens on tip (but 1.16's beta will be soon as well). |
|
Honestly, I don’t think the aesthetics of /v5 is all that bad. It’s the cool new version for the cool kids. And I would prefer it to the aesthetics of +incompatible blah-di-blah and all the drama around this so far. |
|
Could changing package name (forking) be an option? This would provide lagging dependencies with time to adjust, while those who depend directly on chi could move forward with it |
|
Could we keep version v1.5.1? I already upgraded and its works fine for me. |
Yeah! Let's call it different! |
I'm not sure why you are considering /v5 as a bad thing. I have read previous discussions, and my impression - you don't like the aesthetics of the package name, including Adopting 'github.com/go-chi/chi/v5` on the user side will be trivial, and unless you intorduce breaking changes, all users need to do is adding the "/v5" suffix to the import(s). My vote for the standard solution. From my experience, aesthetics reasons in go is a dangerous way leading to insane things, like "exception style" error handing with panic/recover, because someone didn't like |
|
It's crazy to see such a bastion of community love and energy descend to this confusion and chaos over trying to take a stand against where the language has gone. I hope this is reconsidered for the community's sake. I get not liking it. It took me a while to be onboard. I liked some aspects, and my mindset drifted a bit over time to like the rest. What I didn't expect was a maintainer torpedoing a well-loved library to make a point. Saying "this is OSS and not sponsored or paid for in any way, and you always have the choice to fork it and maintain your own versions" feels kind of mean-spirited. Sure, @pkieltyka technically has the right to do whatever, but to suggest dropping the package manager support for the language is kind of hurtful to the other 91 contributors who probably all would prefer a unified place to collaborate and work together. |
That pretty much sums up my entire experience with Go and the Go community. I think of it like some form of Stockholm Syndrome. |
|
@bcmills I've put together a proposal for a backwards-compatible path to make SIV optional and opt-out at the level of an application developer consuming a package -- golang/go#44550 |
I think it's that the Go core team has been thinking about dev problems for a long time, and they have a lot of experience, so they are sometimes able to address a whole problem better than people without their decades of experience. For instance, I wasn't bothered that imports would need to be changed since an IDE or sed or another tool makes that easy. I was bothered by the changeset size in git because I felt that was noise for the sake of noise. However, it's now been pointed out to me that 1. these files that touch an API with a major version update ARE the places where git should point out something changed instead of silent changes being possible anywhere. 2. If I'm working on a large project, my data access or routing or logging imports only touch a couple files, and my other parts of my code are using an interface, and that code is having a change, so it makes sense to me now that I've thought it all through. Now, I don't like having a different folder for a major version, but that approach isn't required. It's just a shim for older versions of Go, and with most the community having implemented go mod now, I don't think we should be worrying about that going forward. |
@PaluMacil I think its fair to say that conceptually the design of this package manager works . However, there is a lot to be desired with the UX of the tool, and because ultimately the UX is how a human is going to interact with the software, a lacking UX leads to a lot of distrust and frustration. Especially when people leave the happy path, as we can see here. |
|
Similar to @aarondl, I've just accepted the change and migrated my old project. Was it annoying? Can I safely rely that updating my dependencies will not break anything? I'm starting a new project but I don't want to deal with the tooling hacks again and decided to pick/write something else. For me in the end, going against the accepted "go module way" of doing things just because of some import path aesthetics is not worth all the troubles. |
|
Another option is doing what protobuf v2 did and change the import path. The new repo can keep the versions at 0.x.x to avoid SIV. The old repo can undo the hacks that are breaking everyone. |
|
hi all, for the greater good of everyone who's adopted chi, I am going to push the v5 with SIV import path. I've submitted my Go proposal golang/go#44550 to the team and have given my best shot at providing a suggestion and perhaps opening a conversation up for building in the ergonomics I'm seeking, but also maintain compatibility with the current module system. I believe the best decision will be made, whether to accept/reject, etc. In any regard whatever is decided, I will need to upgrade to v5 properly, and so I will do so now and see what the future brings. As I prepare to do that, I'd like to get things back on track and continue on a smooth ride for users and past adopters. I've been thinking to "undo" old hacks which block old use, or perhaps just releasing v5 will solve it (but I think not as v1.5.3 retracts other versions)? Please let me know if you have suggestions on how to properly "undo" the hacky version (v1.5.3) so it will cooperate with Go's tooling and existing uses. My thought is the only problematic version is "v1.5.3" of chi, as it retracts all other versions -- can I just remove the v1.5.3 git tag from github to remove it from the history and release v5.0.0? I suspect that will still have wrinkles in it for older adopters of v4.x.x+incompatible or even v1.5.x, as the Go modules remote index will still recognize v1.5.3's existence? thanks |
|
I would make the change to remove the retractions, release it as v1.5.4. Then, switch the paths to v5, tag v5.0.0, and push. IIRC there's some restriction around which modules can retract other modules, since different SIV versions are distinct modules, the above is a straight revert. I would not remove tags. The versions will still persist in caches and proxies. |
|
great news!
I think it will work. Maybe it makes sense to remove the retraction of v4.x.x as well |
|
First off: Thanks a lot for the effort you put into this project 💙 Removing a tagged version, or a whole repository, is always a bad idea for a dependency system. Even when ecosystems learned their lesson after In the FAQs of the Publishing |
|
Sounds like a plan. Here's next steps as I see:
thanks all for your help and patience with this issue. |
|
Both PRs look good to me; the Go tooling looks at whatever is latest for its source of truth, so tagging v1.5.4 will be the "latest" for the old series of releases. The only thing left will be to update the various go-chi org repos that depend on this repo; I'm not sure how many of those were even tagged, just switching their use will be enough. |
|
The other thing I had been thinking about was if it would be worth it to remove go.mod (maybe in some branch), tag a newer v4 (for +incompatible usage), then make the jump to go.mod in a v5 commit. I know there was some code that was intended to be released for everyone, but the downgrade behavior prevented people from using it. Doing so may be beneficial to existing users before they make the change to get v5. I'm not experienced in doing that sort of switch up (to go.mod, away from go.mod, back again, etc), but I think some repos like gofrs/uuid had done something like this previously. If you're comfortable with the contents of the old v4 release, then that's alright too. |
|
chi v5 is out -- https://github.com/go-chi/chi/releases/tag/v5.0.0 please let me know if there are any issues I must admit though, now that I’ve been updating some of my projects to chi v5, I really don’t like it and confirms my original distaste of forced SIV and hassle of all the tooling around it — especially as there is never a good reason to have multiple versions of chi in a single project. |
|
Upgraded a few project to v5 and it worked fine, nothing unexpected. Thx! |
|
The code in EDIT: Hmm, no, I was wrong (it's just from another dep in my dependency graph), but the code there does need to be updated. 🙂 |
@zikaeroh what do you mean? https://github.com/go-chi/chi/blob/master/_examples/hello-world/main.go#L6-L7 ..lol, just shows how poor of a developer experience SIV is, that you're mistakenly loading two versions at once when clearly this is never intended. We must do better with Go modules. I think its time I start learning Rust.. chi.rs is coming, stay tuned :) |
|
I'd like to point out within < 1 day, the basic issues others have with using a package which adopts SIV. The user's intuition isn't the problem here, nor is it my responsibility to be customer support for everyone's project trying to teach them how to use SIV. The problem is with Go's module system and tools.
To me, software is art, and I intentionally spent so much time to craft chi to the create a router with the absolute best ergonomics and developer experience. With forced-SIV, I'm unable to fulfill this purpose. |
There are a few others, I will happily send a PR. #592 to me very much sounds like a GoLand bug; it should work fine with modules and I am sure existing codebases would have hit this for that user. The s3-proxy appears to be a bug in the "renovate" tool; this is some third-party dependency upgrader that doesn't appear to understand SIV and should do better. It seems like https://github.com/renovatebot/renovate/discussions is the place to report issues, but GitHub's search kind of sucks and it's hard to tell if it's been reported already. EDIT: It is. Just in the real "issues" (their marketplace entry links to "discussions"). |
|
FWIW, https://github.com/marwan-at-work/mod is a tool suggested at https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher for automating this process. It's my belief that this tool is likely to be absorbed into golang.org/x/exp/cmd/gorelease (which is intended to eventually be |
|
Actually, https://github.com/marwan-at-work/mod lets you use it as a consumer to quickly get a new version of a module. As does |
I would say this is because users upgrading to v5 successfully and uneventfully won't post success stories. This is expected, supposed to work, and, in practice, works well enough. In all 3 examples, you posted above, this was clearly the user's error or the side effect of the previous downgrade. As with any non-trivial system go mod expects users to understand the basics and not trying to solve problems magically for everyone.
Well, this is sad news as it means a dramatic change for users and a lack of stability from the user's point of view. If from v0.1.0 to v0.2.0 compatibility changed "go get chi" will happily upgrade to the next "major" version potentially breaking user's code. |
and others
I have tried to switch to v1.5.0 from v4.1.2+incompatible but because the version number decreased it caused a downgrade of all other dependencies using chi. For example, I have started with this:
After running
go get github.com/go-chi/chi@v1.5.1I got:As you can see my
pkg/restdowngraded to some old version and such side effects can be very unexpected and unpleasant.Is there a reason why you decided to go with v1.5.x and not with a more traditional (and less dangerous) approach with v5 (also changing the package name to "/v5")? I'm not sure how to deal with this. In order to avoid those unexpected downgrades I have to have all of my dependencies migrated to v1.5, but unfortunately some of them not under my control.
The text was updated successfully, but these errors were encountered: