search

philnash / bitly

🗜 A Ruby wrapper for the bit.ly API
https://rubygems.org/gems/bitly
MIT License
451 stars 139 forks source link

bundler, test dependencies, and v2 and v3 namespacing #5

Closed joshk closed 4 years ago

joshk commented 14 years ago

Hi Phil,

This patch is a bit of a big one (9 commits in total) but it mainly has to do with removing the necessity to mess with the load path, which bundler should be taking care of instead.

There are a bunch of other changes in there, but if you have any questions please let me know.

Thanks for the great gem,

Josh

jcf commented 13 years ago

Can we get this merged please?

saturnflyer commented 13 years ago

+1 for this, although I don't think Gemfile.lock needs to be committed

mtheoryx commented 13 years ago

Committing the Gemfile.lock is pretty much a standard and best practice now. See here, for example.

And also here, right from the source:

Before deploying an app that uses Bundler, Add your Gemfile and Gemfile.lock to source control, but ignore the .bundle folder, which is specific to each machine.

saturnflyer commented 13 years ago

Committing Gemfile.lock is standard practice for your application, not for your gem. The quote from the Bundler docs specifically says "Before deploying a app..."

http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

On Sep 20, 2011, at 12:04 PM, David Poindexterreply@reply.github.com wrote:

Committing the Gemfile.lock is pretty much a standard and best practice now. See here, for example.

And also here, right from the source:

Before deploying an app that uses Bundler, Add your Gemfile and Gemfile.lock to source control, but ignore the .bundle folder, which is specific to each machine.

Reply to this email directly or view it on GitHub: https://github.com/philnash/bitly/pull/5#issuecomment-2146581

mtheoryx commented 13 years ago

Thanks for that clarification, although I still don't see the difference between apps and gems as clearly as others do, I suppose.

joshk commented 13 years ago

You don't want to commit your gemfile lock because it means you aren't testing against more recent versions when you bundle install in development.

While for apps, you want your dependencies to be locked down to what you used in development.

It's a subtle but very big difference.

Sent from my Sega Master System

On 20/09/2011, at 8:38 PM, David Poindexterreply@reply.github.com wrote:

Thanks for that clarification, although I still don't see the difference between apps and gems as clearly as others do, I suppose.

Reply to this email directly or view it on GitHub: https://github.com/philnash/bitly/pull/5#issuecomment-2147708

mtheoryx commented 13 years ago

What I mean is that gems ARE apps for most of my uses. And I cannot test for everything, so once I find a state (gems and versions) that work, I like locking it down to that.

joshk commented 13 years ago

Gems are not apps, no matter how you use them.

That is why when you use a gem in an app you should lock them down for the reasons you say. But if your gemspec is looser than your gemfile then you will experience issues and pain when trying to replicate bugs people report because you do not test the gem correctly.

Sent from my Sega Master System

On 20/09/2011, at 10:21 PM, David Poindexterreply@reply.github.com wrote:

What I mean is that gems ARE apps for most of my uses. And I cannot test for everything, so once I find a state (gems and versions) that work, I like locking it down to that.

Reply to this email directly or view it on GitHub: https://github.com/philnash/bitly/pull/5#issuecomment-2148752

mtheoryx commented 13 years ago

I respectfully disagree. Any gem that has a binary (use bundler with the binstubs directive) that adds to your path and gives you a new command in the terminal absolutely IS an app, IMHO, and by my personal definition of an "app".

There are TONS of those around. Those are not just gems. They are full on apps. Some are even interactive on the command line. Just because the distribution and installation process is "gem" does not mean it's NOT an app unto itself.

joshk commented 13 years ago

Sorry but I think you are wrong, but it sounds like you have made up your mind so I'm not going to argue this further.

There is a good blog post by Yehuda Katz on this subject, you might want to read up on this.

Sent from my Sega Master System

On 20/09/2011, at 10:51 PM, David Poindexterreply@reply.github.com wrote:

I respectfully disagree. Any gem that has a binary (use bundler with the binstubs directive) that adds to your path and gives you a new command in the terminal absolutely IS an app, IMHO, and by my personal definition of an "app".

There are TONS of those around. Those are not just gems. They are full on apps. Some are even interactive on the command line. Just because the distribution and installation process is "gem" does not mean it's NOT an app unto itself.

Reply to this email directly or view it on GitHub: https://github.com/philnash/bitly/pull/5#issuecomment-2149044

mtheoryx commented 13 years ago

I actually met Yehuda in Indianapolis last month. Good guy. Great presentation on SproutCore, actually, at the conference. Not a definitive source on this topic though, from what I can tell. If you'd like to take this offline from this issue, I'm more than happy to. If not, I'm cool with just agreeing to disagree.

jcf commented 13 years ago

@saturnflyer you are right, the Gemfile.lock should not be in there.

@mtheoryx dependencies within a Ruby gem are managed via the gemspec. Because the Gemfile and Gemfile.lock are completely ignored when running gem install bitly, if an exact version of a dependency is required it must be declared in the gemspec.

@joshk can you remove the Gemfile.lock from this pull request?

joshk commented 13 years ago

@jcf My PR is a year old now, it has sat here gathering dust, even if I removed the Gemfile.lock (which I should) Phil isn't going to merge it in. The Gemfile.lock was added based on the lack of best practice at the time.

Anyhow, anyone is free to fork my fork and make the corrections and try to get them pulled in. I forked this repo because we were using it for a project but I saw issues with the code, my changes went ignored without even a comment why they didn't cut the mustard.

I'm not going to delete my fork, but neither do I have time to maintain it due to the workload of Travis CI which I help run.