Bundler 2 compatibility

[spikeheap]

Describe the problem

Bundling a project with this gem and bundler 2 yields the following error:

Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    tty (~> 0.9.1) was resolved to 0.9.1, which depends on
      bundler (< 2.0, ~> 1.16)

  Current Bundler version:
    bundler (2.0.1)
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?

Could not find gem 'bundler (< 2.0, ~> 1.16)', which is required by gem 'tty (~> 0.9.1)', in any of the sources.

This is because Bundler is pinned to <2.0 here.

Steps to reproduce the problem

0. Install Bundler 2.0 or greater.
1. Create a Gemfile with the following:

source 'https://rubygems.org'
gem 'tty', '~> 0.9.1'

2. Run bundle

Describe your environment

• Bundler version: 2.0.1
• OS version: OSX Mojave
• Ruby version: ruby 2.5.1p57
• TTY version: 0.9.1

[piotrmurach]

Hi Ryan!

Great that you're giving this gem a try!

The tty is built on top of bundler. Bundler is not a 'soft' dependency for just installing gems, the tty injects various bits into the gem creation process. Each release of the tty gem has to guarantee the correct working of the terminal apps scaffolding. Imagine for a second this gem specific version is used in 3 years. It would be impossible to predict what bundler 2.7.0 will do, it may be completely incompatible with the current setup. By limiting bundler to a known version, I'm saying that you can trust to always to be able to create terminal applications from this release. Also, the bundler > 2.0.0 only supports Ruby 2.3 onwards. All this has to be tested and locked in future releases.

Additionally, the tty is not a gem you should depend on. It is a metagem used only to provide a way to scaffold a terminal application. In other words, it shouldn't be used in Gemfile. I may add some documentation in line with this.

Therefore, I won't be able to merge your pull request for the reasons mentioned above.

[spikeheap]

Hi Piotr,

Thanks for taking a look, and that sounds fair enough. Bundler follows Semver, so perhaps the PR you're looking for replaces '~> 1.16', '< 2.0' with '>= 1.16', '<= 3.0' (once it's been tested)?

As an aside, ~> 1.16 implicitly excludes >= 2.0.

In the meantime I'll drop this dependency in favour of the specific package. Thanks again for your work on this 💯.

[metalefty]

It would be impossible to predict what bundler 2.7.0 will do, it may be completely incompatible with the current setup.

You need not to accept bundler 2.7.0 but at least accept < 2.1. It is much easier to predict what bundler 2.0.99 would be than 2.7.0, right?

[piotrmurach]

@spikeheap The fact that bundler follows semver, at least in my understanding, means that current APIs won't break. However, this doesn't mean that internal APIs won't change including code refactorings. I'm relying on the gem command and inject a few bits of scaffolding into the generated files. In the past, even the format of gemspec has changed which will break the scaffolding process. I know this is brittle but I don't know a better way yet.

@metalefty Not necessarily. Please see my comment above.

One idea I had is to actually vendor a version of bundler inside the gem and reference it relatively. Then the gem itself wouldn't specify a dependency on bundler at all. Any new release of tty would mean pulling latest bundler and testing against it. One drawback is that if bundler gets patches, and on average it gets about 10 a year, all these will have to be manually updated. Is this a problem? In the grand scheme of things not really because the only bit of bundler that I need is the gem generation command that will probably change less often.

Any ideas/comments appreciated.

[piotrmurach]

Small update on this issue. I decided that I'm going to drop dependency on bundler all together and forge my own solution for scaffolding a brand new gem setup. It's too unpredictable to keep building on bundler. However, this is also a significant undertaking for which I need some uninterrupted chunk of time. You will see commits being made against this issue once I start working on it.

[dbalatero]

I really wanted to use this, but I'll have to drop down to doing it myself with thor, as bundler has pushed way past 2.x.

[piotrmurach]

@dbalatero I hope you won't give up on tty! Here's a little bit of update and plan:

1. Update all tty components(more than 20) and change bundler to 2.0: (in progress)

• Remove Ruby 2.7 warnings
• Change gemspecs to remove file artifacts like tests and hence make the tty gems even smaller
• Change bundler dependency to use 2.0

2. Rewrite tty gem to stop relying on Bundler to setup a new CLI apps.

• Add scaffolding for a new gem with best practices learnt such as gemspecs - Writing a Ruby Gem Specification explains my thinking better.
• Change generated dependencies and allow the choice of what tty components are needed rather than preinstall them all. Split between core and nice to have components.

3. Change tty architecture/design:

• Add templates handling support
• New way to create commands without relying on Thor
• Expose simple but powerful methods for commands implementation
• Make the testing a really smooth experience (few issues reported already)

I know roughly what I want the project to look like and behave. The only thing is the time! I really wish I could spend more time on this. I need to figure out how to get funding though.

[dbalatero]

It sounds like a good plan! Unfortunately I gotta keep rolling on my thing, but I'll check in next time I have a CLI-oriented project!

edit: also thor had really disappointing docs so I ended up just rolling my own really lite command system, sigh.

[bopm]

@piotrmurach any news in that effort? Absolutely fabulous project you have here, but absence of Bundler 2 support is a downer.

[piotrmurach]

@bopm My plan is to start working on this from the next week. I cannot give you a deadline but my main focus will be on switching to Bundler 2 support. I'm currently finishing a new tty-option gem that, in future, will power options parsing.

[bopm]

@piotrmurach great to know, I have some itch in moving some of my bash scripts to your framework, but as projects are all on bundler 2, it blocking me. I can probably even offer some help, if any needed.

[piotrmurach]

@bopm To clarify. Don't let the Bundler version delay you. Bundler is only used to generate your CLI app structure - it isn't a dependency for a new project. To use older bundler, you can do bundle _1.17.3_ .... Once your CLI app gets generated, you can use whatever Bundler version you want to manage your dependencies. Plus this would be a good experience. If you notice things missing or have suggestions on improvements you can submit issues for discussion or PRs and they can be merged into this new release.

[DNA]

@piotrmurach I think the plan you've posted on mar/3 is a really nice roadmap for TTY 1.0!

Why don't you create a project for it on GH and split all those steps into issues? I'd be easier for us to know what to do and how to help :)

[piotrmurach]

@DNA Thank you for the interest! I know it's a bit disappointing to still see this issue here. I can assure you that I'm annoyed as well. I'm painfully aware that the Bundler issue is preventing a lot of people from using tty and having a good experience. So that's why I'm currently full steam ahead on the first point of the 'grand' plan.

I finished recently the tty-option gem which will serve as a replacement for thor dependency in the third point of the 'grand' plan. I'm in the process of updating all the tty components. Unfortunately, this has to be done in a certain order given that, for example, tty-screen is a dependency for a few other components. As I'm releasing new versions, I try to tackle more pressing issues on individual projects.

The way I can see people contributing and providing help at this stage is by triaging issues or fixing bugs on a specific tty project.

[cwant]

My team has been enjoying using an older version of tty. We looked at upgrading today to use a newer feature and got bit by this (in this case we are developing for a large shared scientific cluster, and have less control over core dependencies like bundler). I just wanted to add a "me too", so this issue doesn't fall between the cracks.

[mike-yesware]

@piotrmurach What help do you need to get a release cut? Is there any harm in releasing 0.11 ASAP? How can the community help get the release out?

[piotrmurach]

@cwant Thank you for your comment Chris. This issue is solved in the master branch. Unfortunately, the gem is not ready for release yet. I have a system where I truck all issues/features in my open-source projects and nothing escapes my attention. In order for tty to be released, I needed to update and release 25 tty components which took more than one year. Now, the tty project itself requires updating in line with all the changes, checking against newer bundler releases and fixing reported bugs in this very issue tracker. This all takes time and I do it in my limited spare time. If you wish for this project and related tty projects to get developed, you can consider contributing your time reviewing issues, submitting PRs or sponsoring me. Any help is welcome.

[piotrmurach]

@mike-yesware Thanks for you comment Mike. I appreciate your enthusiasm for making a new release. But the tty isn't ready to be released yet. It's not far away though. There are issues including this issue 78 that is a show stopper. In my quick investigation, the tty-command component is at fault and in particular this issue. There are other things that require attention and updates. Unfortunately, I do not have a solid chunk of time at the moment to focus on making a new release. So you wonder how you and community can help? The mentioned issue would be a good start. Triaging and reviewing issues in this very issue tracker is a good next step. Apart from contributing your time and code, you can also consider supporting me to find time to work on tty projects. I really do hope to work on a new release soon but I cannot promise anything.

[aovertus]

@piotrmurach is there a way we could fetch the unreleased version in a gemspec ? We maintain a custom version of broadside which require tty. https://github.com/lumoslabs/broadside/blob/master/broadside.gemspec#L26

We can't move to bundler 2 because of this 😿

[piotrmurach]

@aovertus The tty gem is only used for scaffolding new CLIs and shouldn't be used as a direct dependency. Looking at the broadside gem source, you only use tty-table and my recommendation would be to replace your dependency with spec.add_dependency 'tty-table', '~> 0.12.0.

[aovertus]

@aovertus The tty gem is only used for scaffolding new CLIs and shouldn't be used as a direct dependency. Looking at the broadside gem source, you only use tty-table and my recommendation would be to replace your dependency with spec.add_dependency 'tty-table', '~> 0.12.0.

Thanks for the feedback we were able to fix the issue doing so 😁

[qume]

@bopm To clarify. Don't let the Bundler version delay you. Bundler is only used to generate your CLI app structure - it isn't a dependency for a new project. To use older bundler, you can do bundle _1.17.3_ .... Once your CLI app gets generated, you can use whatever Bundler version you want to manage your dependencies. Plus this would be a good experience. If you notice things missing or have suggestions on improvements you can submit issues for discussion or PRs and they can be merged into this new release.

I think you should consider putting a version of this message right at the top of the main repo markup page. I was about to give up on this, but then read this comment and had it working 20 seconds later (after an hour of trying to get it to work).

I had no idea using an old version of bundler was so easy, and doesn't change the system state. Given how straight forward it is, perhaps staying on the old version of bundler longer term isn't really a problem for this project.

[carld]

Hi,
This gem looks great, I tried the quick start guide from https://ttytoolkit.org and unfortunately ran into this issue,

Carls-MacBook-Pro:educational Carl$ gem install tty
Successfully installed tty-0.10.0
Parsing documentation for tty-0.10.0
Done installing documentation for tty after 0 seconds
1 gem installed
Carls-MacBook-Pro:educational Carl$ teletype new app
Traceback (most recent call last):
	7: from /Users/Carl_1/.rvm/gems/ruby-2.7.6/bin/ruby_executable_hooks:22:in `<main>'
	6: from /Users/Carl_1/.rvm/gems/ruby-2.7.6/bin/ruby_executable_hooks:22:in `eval'
	5: from /Users/Carl_1/.rvm/gems/ruby-2.7.6/bin/teletype:23:in `<main>'
	4: from /Users/Carl_1/.rvm/rubies/ruby-2.7.6/lib/ruby/2.7.0/rubygems.rb:297:in `activate_bin_path'
	3: from /Users/Carl_1/.rvm/rubies/ruby-2.7.6/lib/ruby/2.7.0/rubygems.rb:297:in `synchronize'
	2: from /Users/Carl_1/.rvm/rubies/ruby-2.7.6/lib/ruby/2.7.0/rubygems.rb:298:in `block in activate_bin_path'
	1: from /Users/Carl_1/.rvm/rubies/ruby-2.7.6/lib/ruby/2.7.0/rubygems/specification.rb:1369:in `activate'
/Users/Carl_1/.rvm/rubies/ruby-2.7.6/lib/ruby/2.7.0/rubygems/specification.rb:2247:in `raise_if_conflicts': Unable to activate tty-0.10.0, because bundler-2.3.21 conflicts with bundler (~> 1.16, < 2.0) (Gem::ConflictError)

I suspect a solution will be to use rvm to get a setup that is compatible with tty, just thought I'd check in here in case there's other solutions.

Thanks,
Carl

[hopsoft]

Here's what I did to get up and running with tty

# bash console
asdf install ruby 2.7.8
asdf local ruby 2.7.8
gem install bundler -v 1.17.3

# Gemfile
ruby "2.7.8"
gem "tty"

# bash console
bundle _1.17.3_