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

Update unicode-display_width #60

Open
KieranP opened this issue Mar 25, 2025 · 4 comments
Open

Update unicode-display_width #60

KieranP opened this issue Mar 25, 2025 · 4 comments
Labels

Comments

@KieranP
Copy link

KieranP commented Mar 25, 2025

The current gem dependencies restricts unicode-display_width to ">= 1.6", "< 3.0".

In my project, we use rspec, which allows unicode-display_width >= 2.4.0, < 4.0.

This means our project uses the latest unicode-display_width, 3.1.4.

So when I try to install tty-progressbar, it installs version 0.14.0, instead of the latest.

Can tty-progressbar be updated to work with unicode-display_width <4.0 ?

@KieranP
Copy link
Author

KieranP commented Mar 25, 2025

PR here: #61

@piotrmurach
Copy link
Owner

Thank you for submitting this issue.

In my project, we use rspec, which allows unicode-display_width >= 2.4.0, < 4.0.

I believe you meant rubocop as rspec doesn't have a direct dependency on the unicode-display_width.

So when I try to install tty-progressbar, it installs version 0.14.0, instead of the latest.

When I replicate a minimal scenario with rubocop and tty-progressbar gems in a Gemfile. The bundler resolves both dependencies to the latest with unicode-display_width at 2.6.0 version. This matches my expectations.

Can tty-progressbar be updated to work with unicode-display_width <4.0 ?

I have nothing against relaxing the upper constraint to include any 3.* version, provided there are no breaking changes.

@KieranP
Copy link
Author

KieranP commented Mar 26, 2025

I believe you meant rubocop as rspec doesn't have a direct dependency on the unicode-display_width.

Yes, my mistake, I did mean rubocop.

When I replicate a minimal scenario with rubocop and tty-progressbar gems in a Gemfile. The bundler resolves both dependencies to the latest with unicode-display_width at 2.6.0 version. This matches my expectations.

It happens when rubocop is installed first. i.e. if you add tty-progressbar to an existing project, it will install the old version.

> bundle init

› bundle add rubocop
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Fetching parser 3.3.7.3
Installing parser 3.3.7.3
Fetching rubocop-ast 1.43.0
Installing rubocop-ast 1.43.0
Fetching rubocop 1.75.1
Installing rubocop 1.75.1

› bundle add tty-progressbar
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Fetching tty-cursor 0.5.0
Fetching tty-screen 0.6.5
Installing tty-cursor 0.5.0
Installing tty-screen 0.6.5
Fetching tty-progressbar 0.14.0
Installing tty-progressbar 0.14.0

Note that tty-progressbar 0.14.0 is installed.

I have nothing against relaxing the upper constraint to include any 3.* version, provided there are no breaking changes.

I created a PR here: #61 - Looks like older ruby versions are no longer supported. Given that the minimum supported version of Ruby 2.4 was released 8+ years ago, perhaps it would be good to drop the CI checks for older rubies?

@piotrmurach
Copy link
Owner

It happens when rubocop is installed first. i.e. if you add tty-progressbar to an existing project, it will install the old version.

Fair enough, the bundler resolution prioritises the existing dependencies.

I created a PR here: #61

Great!

Looks like older ruby versions are no longer supported. Given that the minimum supported version of Ruby 2.4 was released 8+ years ago, perhaps it would be good to drop the CI checks for older rubies?

All the tty gems support Ruby 2.0 or higher. That's a deliberate choice. It embraces the nature of terminal applications and their distribution. Many gems are distributed and built by various Linux distros. Not using the latest features keeps internals more portable. When I started writing tty gems more than a decade ago, it was to make CLI apps easy to build. But also as I was creating the gems, I wanted to have an easy way to build self-contained executables similar to Go. Part of that idea was being able to port the gems to mruby. This would allow the gems to be used, for example, within embedded systems. Therefore, I won't be dropping support for older versions for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants