v2 may sometimes fail #429

New issue

Closed

opened 2026-03-04 01:04:53 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:04:53 +03:00

Owner

Originally created by @spinzed on GitHub (Apr 2, 2021).
Original GitHub issue: https://github.com/rivo/tview/issues/586

Since updating to tcell v2, using tcell's types and constants has created an issue when upgrading. If the project is created with tview version which uses v1 of tcell and it is attempted to update go get -u command, it will refuse to update with bunch of errors like this one:

./main.go:27:38: cannot use "github.com/gdamore/tcell".AttrBold (type "github.com/gdamore/tcell".AttrMask) as type "github.com/gdamore/tcell/v2".AttrMask in argument to grid.Box.SetBorderAttributes

The types are wrong, types from tcell/v2 are expected, but the project contains those from tcell/v1. This can be resolved by appending /v2 to the tcell import paths in all project files. But that still breaks compatibility and can happen again in the future.

The obvious solution is that the package should not rely on tcell's types and it should have their own that are analog to tcell's. This should be easily implemented with type aliases. It should prevent that error from happening in the future, although the problem will still be present for those who already started a project with the old version of tcell.

Originally created by @spinzed on GitHub (Apr 2, 2021). Original GitHub issue: https://github.com/rivo/tview/issues/586 Since updating to tcell v2, using tcell's types and constants has created an issue when upgrading. If the project is created with tview version which uses v1 of tcell and it is attempted to update `go get -u` command, it will refuse to update with bunch of errors like this one: ``` ./main.go:27:38: cannot use "github.com/gdamore/tcell".AttrBold (type "github.com/gdamore/tcell".AttrMask) as type "github.com/gdamore/tcell/v2".AttrMask in argument to grid.Box.SetBorderAttributes ``` The types are wrong, types from `tcell/v2` are expected, but the project contains those from `tcell/v1`. This can be resolved by appending `/v2` to the tcell import paths in all project files. But that still breaks compatibility and can happen again in the future. The obvious solution is that the package should not rely on tcell's types and it should have their own that are analog to tcell's. This should be easily implemented with type aliases. It should prevent that error from happening in the future, although the problem will still be present for those who already started a project with the old version of tcell.

kerem closed this issue

2026-03-04 01:04:53 +03:00

kerem commented

2026-03-04 01:04:54 +03:00

Author

Owner

@rivo commented on GitHub (Apr 26, 2021):

I understand that this is frustrating. While I try hard not to break backwards compatibility, tcell did (I'm guessing @gdamore had to due to limitations of the old formats) and the only way to avoid breaking changes in tview was to not upgrade. But many bugs that also affected tview were fixed in the new tcell version so that was no viable option.

What you're suggesting is breaking compatibility once again by wrapping tcell types with tview types. Is that a good idea?

By the way, this was suggested before and even back then, I explained that it wouldn't just be the types but also all of tcell's constants. And if any of that changes in tcell, I'd have to remap everything (dynamically in the worst case). I'd rather put the little time I have into tview's own features than to copy (and maintain) code from tcell.

Overall, that's a "no" for now. I'm hoping @gdamore won't make more changes to the basic types such as Color, AttrMask, Style, and Key. If he doesn't, we should be fine.

@rivo commented on GitHub (Apr 26, 2021): I understand that this is frustrating. While I try hard not to break backwards compatibility, `tcell` did (I'm guessing @gdamore had to due to limitations of the old formats) and the only way to avoid breaking changes in `tview` was to not upgrade. But many bugs that also affected `tview` were fixed in the new `tcell` version so that was no viable option. What you're suggesting is breaking compatibility once again by wrapping `tcell` types with `tview` types. Is that a good idea? By the way, this was suggested before and even back then, I explained that it wouldn't just be the types but also all of `tcell`'s constants. And if any of that changes in `tcell`, I'd have to remap everything (dynamically in the worst case). I'd rather put the little time I have into `tview`'s own features than to copy (and maintain) code from `tcell`. Overall, that's a "no" for now. I'm hoping @gdamore won't make more changes to the basic types such as `Color`, `AttrMask`, `Style`, and `Key`. If he doesn't, we should be fine.

kerem commented

2026-03-04 01:04:54 +03:00

Author

Owner

@gdamore commented on GitHub (Apr 26, 2021):

I have no plans to do so. We could not make the improvements to fix some of the bugs without the breaking change - I try hard not to do breaking changes but it was unavoidable in this case.

@gdamore commented on GitHub (Apr 26, 2021): I have no plans to do so. We could not make the improvements to fix some of the bugs without the breaking change - I try hard not to do breaking changes but it was unavoidable in this case.

kerem commented

2026-03-04 01:04:54 +03:00

Author

Owner

@rivo commented on GitHub (Apr 26, 2021):

Thanks for chiming in. That's what I had thought. All good.

@rivo commented on GitHub (Apr 26, 2021): Thanks for chiming in. That's what I had thought. All good.

kerem commented

2026-03-04 01:04:54 +03:00

Author

Owner

@spinzed commented on GitHub (Apr 26, 2021):

If that's the case, perhaps it's best to leave it as is. The fewer breaking changes are there, the better.
I'll close this issue since we clarified all things we needed to clarify.

@spinzed commented on GitHub (Apr 26, 2021): If that's the case, perhaps it's best to leave it as is. The fewer breaking changes are there, the better. I'll close this issue since we clarified all things we needed to clarify.