0

When authoring a gem, what would be reccomended practice for version restrictions of dependencies. For example I know that know that my gem works wih rubyzip version 2.x, but I also know that it works for 1.9 as well. Should I state 

spec.add_runtime_dependency 'rubyzip', '>1.8'

or if the rubyzip version 1.9 is long time outdated, it is more common to "push" change for 2.x line? Also if I use the mentioned line, that I risk incompability with future versions, but on the other hand, leave the coice to the user.

Note: the questions is generall and dependency on rubyzip is just an example.

gorn
  • 5,042
  • 7
  • 31
  • 46
  • What about `'>=1.9', '<3'` – Stefan May 21 '19 at 10:52
  • As for the close votes - I ask for best practices, which usualy contain not only opinion, but arguments like security, "least surprise", usability. This questin in also valuable just because the answer is NOT contained in any existing documentation (I am aware of). – gorn May 21 '19 at 14:44

1 Answers1

2

If you know that your gem works with rubyzip 1.9, then there's really no need to force people to use >=2.0 with it.

Sure, updating dependencies would be a good idea for your library-user to do, but it's not your job to be the "update-your-software-police"!

Specifying that the version must be < 3 is generally advisable (although not consistently done by developers), as there's a reasonable risk that a major dependency version bump will be incompatible with this version of your code.

So, as a compromise, you could do:

spec.add_runtime_dependency 'rubyzip', '>=1.9', '<3'

See the documentation for valid syntax examples.

Tom Lord
  • 27,404
  • 4
  • 50
  • 77
  • I know the possible syntax, the question was more about if this is recommended strategy. Is it reccomended to leave dependencies as wide as possible? – gorn May 21 '19 at 12:27
  • I already answered that. No, it's typically better to set an upper bound on the major version at least. Otherwise, it can be painfully difficult to track down the cause of bugs when upgrading lots of dependencies in a project. – Tom Lord May 21 '19 at 12:43
  • For example, look at [the gemspec for `bundler`; the most heavily downloaded ruby gem](https://github.com/bundler/bundler/blob/abc124185b57c42fe61ee64603676d050d37bb15/bundler.gemspec#L37-L42). Some dependencies are (intentionally) even more strict, but none of them lack an upper bound. – Tom Lord May 21 '19 at 12:45
  • There are exceptions; use your own best judgement. – Tom Lord May 21 '19 at 12:46
  • I disagree. I would argue that you should leave dependencies as wide as possible. I see no benefit in telling people not to use a gem just because you were not able to test your gem against that future version in the past. If there is no clue that a future version might break you gem then to be too strict. – spickermann May 21 '19 at 12:52
  • @spickermann I appreciate that this is a somewhat opinionated answer (and so is arguably unsuitable for SO!), but in my defence [the rubygems website states](https://guides.rubygems.org/patterns/#declaring-dependencies): *"The important note to take home here is to be aware others will be using your gems, so guard yourself from potential bugs/failures in future releases by using `~>` instead of `>=` if at all possible."* -- and I think the rubygems website is the closest one can get to "recommended practice" guidelines. – Tom Lord May 21 '19 at 13:48
  • Rake is a great example, which shows usage of ~> which is what I see on most occasions. However it also uses rake ~> 12.0 which is somewhat discutable - I have been using 10.5 until recently (debian stable) and I doubt they are incompatible with at least ver 11.0. So assording to your answer they should have probably used `">=10.0", "<13.0". Am I right? – gorn May 21 '19 at 14:39
  • 1
    @gorn *"I doubt they are incompatible..."* -- If they are not incompatible then yes, in my opinion, that would have been a more "community-friendly" design. But I do not know if your presumption about compatibility is true. – Tom Lord May 21 '19 at 14:46
  • In fact @gorn, I did a quick git blame out of interest and sure enough: [There is a good reason why that constraint was added](https://github.com/bundler/bundler/commit/233de9dba18c815a00ba4a1ba31e1ccb05f0ec25). Rake v10/v11 is incompatible (noisy deprecation warnings) with ruby 2.7 - so they have raised the requirement in the master branch. – Tom Lord May 21 '19 at 14:54
  • Well that is for broader discussion about "compatibility matrix", because I try also support 1.9 rubies etc .... However, thanks for your help, I will use this. Hopefully the opinion given is also best practice ... – gorn May 21 '19 at 14:55