search

DruRly / gemrat

Save Time. Add the latest version of gems to your Gemfile from the command line.
http://bit.ly/18O9sNO
MIT License
170 stars 12 forks source link

Use `~>` #10

Closed moonglum closed 11 years ago

moonglum commented 11 years ago

I suggest to put the version as ~> in the Gemfile. This is recommended and most people will change it to that anyway. If you do not think this is generally applicable, maybe make it an option?

PS: Great gem. I really like it! Makes an awesome workflow :dancer: Thanks for that!

DruRly commented 11 years ago

Thanks Lucas. I'm glad that you find it useful. Making this an option isn't a bad idea but I wouldn't suggest this as default behavior. When I ship an app, I expect it to work a certain way and wouldn't leave any room for error. I've seen people shoot themselves in the foot with this approach too many times.

moonglum commented 11 years ago

Ok, if I would send you a pull request that would add this behavior if and only if either:

  1. You call gemrat --pessimistic-operator GEM, or
  2. ~/.gemratrc contains --pessimistic-operator

... would you accept it? :wink: (The name pessimistic operator comes from the RubyGems User Guide.

DruRly commented 11 years ago

Could you also include support for optimistic versioning? And I like the idea of having aliases for "--pessimistic-operator" and "--optimistic-operator". I love explicitness but these are fairly long option names. I think there should be an optional syntax much like "--help" and "-h" works. Maybe "-p" and "-o"?

And sure I'll accept it! :wink:

shime commented 11 years ago

@DruRly, maybe it's a good idea to provide less tight dependencies by default? Check out the Bundler rationale, specifically the section named FAQ: Why Can't I Just Specify Only = Dependencies?.

I'm under impression that loosening up the version dependencies is a good thing in most cases.

Thoughts?

moonglum commented 11 years ago

Both options should be offered! I personally agree with @shime :smile: but the default should be decided by the mainainer of the project: @DruRly :smile_cat:

DruRly commented 11 years ago

@shime I agree with the link you posted in that gems should be extremely lenient about versioning requirements. My philosophy comes from personal experience and developers who I highly respect. I think it was John Barnette who really made this sink in with me. Dependencies should be loose for gems and tight in apps.

I understand that in most cases pessimistic versioning should be ok but every maintainer isn't going to save breaking changes for a major version bump. They should but everyone has a story of someone who didn't. I feel like we face enough uncertainty around breaking changes when dealing with 3rd-party APIs. I wouldn't consciously bring such pain onto myself or other developers.

This goes along with why I built gemrat. It's easy enough to add a gem to a gemfile and bundle. I grew tired of looking up versions but I needed versions because I'd been on large distributed teams where someone ran bundle update and then committed. Using locked versions does require altering the version number for updates but this process becomes explicit and intentional.

The majority of users don't seem to mind exact versioning and understand the risks of not locking these things in. For developers who have worked in smaller teams or alone, they may have never had the type of issues that scare a lot of people.

Pessimistic won't be a default anytime soon but I will keep an eye on the community as to avoid a case of Rails/Test::Unit craziness.

I think @moonglum has a great idea regarding the .gemratrc file and if it turns out that most people prefer pessimistic versioning, I'll accept it and resort to specifying the --exact option as my personal default.