From 9c91c87041cf8f0880acc94fd84de0cdb0294036 Mon Sep 17 00:00:00 2001 From: "Samuel E. Giddins" Date: Mon, 30 Nov 2015 15:11:15 -0600 Subject: [PATCH 01/10] Add Heroku generated app.json --- app.json | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 app.json diff --git a/app.json b/app.json new file mode 100644 index 0000000000..db88d4649c --- /dev/null +++ b/app.json @@ -0,0 +1,16 @@ +{ + "name": "bundler-site", + "scripts": { + }, + "env": { + "LANG": { + "required": true + }, + "RACK_ENV": { + "required": true + } + }, + "addons": [ + + ] +} From abfdd44f2e505b4216750ba66bc5337cacd1b6d5 Mon Sep 17 00:00:00 2001 From: Samuel Giddins Date: Tue, 1 Dec 2015 22:34:24 -0600 Subject: [PATCH 02/10] [Rakefile] Treat man pages as normal source --- .gitignore | 7 ++++++- Rakefile | 12 +++++++----- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/.gitignore b/.gitignore index e501498958..a41cc82697 100644 --- a/.gitignore +++ b/.gitignore @@ -23,5 +23,10 @@ # Bundler binstubs /bin +# pages from the bundler repo source/issues.md -source/conduct.md \ No newline at end of file +source/conduct.md + +# man pages built from the bundler repo +/source/man/ +/source/v*/man/ diff --git a/Rakefile b/Rakefile index e4b349b8b3..64c6578043 100644 --- a/Rakefile +++ b/Rakefile @@ -20,19 +20,21 @@ task :man => [:update_vendor] do VERSIONS.each do |version| branch = (version[1..-1].split('.') + %w(stable)).join('-') - mkdir_p "build/#{version}/man" + rm_rf "source/#{version}/man" + mkdir_p "source/#{version}/man" Dir.chdir "vendor/bundler" do sh "git reset --hard HEAD" sh "git checkout origin/#{branch}" sh "ronn -5 man/*.ronn" - cp(FileList["man/*.html"], "../../build/#{version}/man") + cp(FileList["man/*.html"], "../../source/#{version}/man") sh "git clean -fd" end end # Make man pages for the latest version available at the top level, too. - cp_r "build/#{VERSIONS.last}/man", "build" + rm_rf "source/man" + cp_r "source/#{VERSIONS.last}/man", "source" end desc "Pulls in pages maintained in the bundler repo." @@ -58,12 +60,12 @@ task :update_site => ["vendor/bundler.github.io"] do end desc "Build the static site" -task :build => [:repo_pages] do +task :build => [:repo_pages, :man] do sh "middleman build --clean" end desc "Release the current commit to bundler/bundler.github.io" -task :release => [:build, :man, :update_site] do +task :release => [:build, :update_site] do commit = `git rev-parse HEAD`.chomp Dir.chdir "vendor/bundler.github.io" do From 6421b92af9c2ddeb64e4d5d077db54da879abc47 Mon Sep 17 00:00:00 2001 From: Dennis Paagman Date: Wed, 2 Dec 2015 13:29:53 +0100 Subject: [PATCH 03/10] Fix anchor in links to RubyGems version specifiers page --- source/v1.0/gemfile.haml | 2 +- source/v1.1/gemfile.haml | 2 +- source/v1.10/gemfile.haml | 2 +- source/v1.2/gemfile.haml | 2 +- source/v1.3/gemfile.haml | 2 +- source/v1.5/gemfile.haml | 2 +- source/v1.6/gemfile.haml | 2 +- source/v1.7/gemfile.haml | 2 +- source/v1.8/gemfile.haml | 2 +- source/v1.9/gemfile.haml | 2 +- 10 files changed, 10 insertions(+), 10 deletions(-) diff --git a/source/v1.0/gemfile.haml b/source/v1.0/gemfile.haml index 6ec8927c5b..b45713946a 100644 --- a/source/v1.0/gemfile.haml +++ b/source/v1.0/gemfile.haml @@ -39,7 +39,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to("RubyGems version specifiers", "http://guides.rubygems.org/patterns/#pessimistic_version_constraint") + = link_to("RubyGems version specifiers", "http://guides.rubygems.org/patterns/#pessimistic-version-constraint") .bullet .description diff --git a/source/v1.1/gemfile.haml b/source/v1.1/gemfile.haml index ecf73afef0..8956b8e02f 100644 --- a/source/v1.1/gemfile.haml +++ b/source/v1.1/gemfile.haml @@ -39,7 +39,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.10/gemfile.haml b/source/v1.10/gemfile.haml index ff25283e80..9f318f99a6 100644 --- a/source/v1.10/gemfile.haml +++ b/source/v1.10/gemfile.haml @@ -54,7 +54,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.2/gemfile.haml b/source/v1.2/gemfile.haml index 6d4df60eb4..a532f72bc5 100644 --- a/source/v1.2/gemfile.haml +++ b/source/v1.2/gemfile.haml @@ -39,7 +39,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.3/gemfile.haml b/source/v1.3/gemfile.haml index a31bf1ccf4..ace96ce17e 100644 --- a/source/v1.3/gemfile.haml +++ b/source/v1.3/gemfile.haml @@ -33,7 +33,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.5/gemfile.haml b/source/v1.5/gemfile.haml index a31bf1ccf4..ace96ce17e 100644 --- a/source/v1.5/gemfile.haml +++ b/source/v1.5/gemfile.haml @@ -33,7 +33,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.6/gemfile.haml b/source/v1.6/gemfile.haml index d44b0ea190..cbf0ef4937 100644 --- a/source/v1.6/gemfile.haml +++ b/source/v1.6/gemfile.haml @@ -52,7 +52,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.7/gemfile.haml b/source/v1.7/gemfile.haml index 1261c98584..034e6d2f61 100644 --- a/source/v1.7/gemfile.haml +++ b/source/v1.7/gemfile.haml @@ -54,7 +54,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.8/gemfile.haml b/source/v1.8/gemfile.haml index ff25283e80..9f318f99a6 100644 --- a/source/v1.8/gemfile.haml +++ b/source/v1.8/gemfile.haml @@ -54,7 +54,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description diff --git a/source/v1.9/gemfile.haml b/source/v1.9/gemfile.haml index ff25283e80..9f318f99a6 100644 --- a/source/v1.9/gemfile.haml +++ b/source/v1.9/gemfile.haml @@ -54,7 +54,7 @@ ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic_version_constraint' + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description From 9d13e1f980298008d5a79d2c6a2957ee4eb1bb77 Mon Sep 17 00:00:00 2001 From: Samuel Giddins Date: Sat, 12 Dec 2015 11:10:20 -0800 Subject: [PATCH 04/10] Add 1.11 announcement post --- .../blog/2015-12-12-version-1-11-released.md | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 source/blog/2015-12-12-version-1-11-released.md diff --git a/source/blog/2015-12-12-version-1-11-released.md b/source/blog/2015-12-12-version-1-11-released.md new file mode 100644 index 0000000000..d20e4ccd7f --- /dev/null +++ b/source/blog/2015-12-12-version-1-11-released.md @@ -0,0 +1,75 @@ +--- +title: Version 1.11 released +date: 2015-12-12 19:00 UTC +tags: +author: Samuel Giddins +author_url: http://segiddins.me +category: release +--- + +Bundler 1.11 is here! Six and a half months after the last big release, we're +finally ready to ship 1.11. + +I know it's been a while, but there's a pretty good reason for that. Over the +summer, the team was busy supervising _four_ Google Summer of Code students: + +- We made a significant amount of progress on the new compact gem index, which +- ought to ship in 1.12 in the near future. We improved some of the bundler web +- properties. We've got a solid base in place for Bundler 2.0. We prototyped a +- new plugin system. + +In addition, the Bundler Core team has spent a lot of time focusing on the +development experience of bundler itself. The bundler codebase is over five +years old, and contains code from over 400 contributors. That can make it rather +daunting to start contributing, and also makes it hard to ensure that all of the +code in bundler is up to the same standards (and is fit to last for the next +five years!). In order to make things more consistent, we've introduced RuboCop +(and thus a style guide) to bundler, have instituted a build bot to ensure that +`master` is never failing, and have decided to subject 100% of the new code +introduced to code review. This is a big step forward, and lets me confidently +say that this will be our best release yet! + +That out of the way, what's actually in this long-awaited release? + +### New features + +First up, we've combed through a few years worth of bundler issues, and have +improved the error messaging for every single one of them. Our goal is to never +show the full 'issue report template', and instead present a friendly and +helpful error message when things go awry -- and we're now pretty close to that. + +The dependency resolver has also seen a few updates. Continuing the theme of +improved errors, version conflicts will now do a better job of reporting what +versions of every gem have been activated, making it even easier to figure out +the best way to resolve said conflict. Additionally, resolution has been sped up +by over 25x in pathological cases. That's a pretty nice win. + +Finally, we've laid the groundwork for being able to take into account +`required_ruby_version` when resolving -- once the new index is rolled out, if +you specify a ruby version in your Gemfile, bundler will make sure to only +resolve for compatible gemspecs. + +### Bugfixes + +The real meat of this release comes in the bugfix section, however. Across +almost four hundred commits, we've squashed upwards of fifty unique bugs. +Meaning this version of bundler should be the fastest, most stable version we've +ever released. + +### What's Next + +As I mentioned earlier, this long gap between releases doesn't mean we're +slowing down development -- quite the opposite, in fact! We're actively working +on bundler 1.12 and 2.0 _at this very moment_, and are incredibly exited to get +the new index into people's hands as fast as we possibly can. + +#### Updating + +To install the last release of Bundler, you can run: + +``` +$ [sudo] gem install bundler +``` + +For all the details, don’t miss the +[Changelog](https://github.com/bundler/bundler/blob/v1.11.0/CHANGELOG.md#1110-2015-12-12)! From 900c5dfb5d53c886ed92406cc0ca48662314cef3 Mon Sep 17 00:00:00 2001 From: Andre Arko Date: Sun, 13 Dec 2015 09:37:21 +0800 Subject: [PATCH 05/10] Small tweaks to formatting and language - Separate bullet points - Capitalize "Bundler" - Clarify error handling goal is to avoid backtraces - Note that Gemfile Ruby is not required for resolving with Ruby version --- .../blog/2015-12-12-version-1-11-released.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/source/blog/2015-12-12-version-1-11-released.md b/source/blog/2015-12-12-version-1-11-released.md index d20e4ccd7f..2d1d14a780 100644 --- a/source/blog/2015-12-12-version-1-11-released.md +++ b/source/blog/2015-12-12-version-1-11-released.md @@ -13,21 +13,22 @@ finally ready to ship 1.11. I know it's been a while, but there's a pretty good reason for that. Over the summer, the team was busy supervising _four_ Google Summer of Code students: -- We made a significant amount of progress on the new compact gem index, which -- ought to ship in 1.12 in the near future. We improved some of the bundler web -- properties. We've got a solid base in place for Bundler 2.0. We prototyped a -- new plugin system. + - We made a significant amount of progress on the new compact gem index, which + ought to ship in 1.12 in the near future. + - We improved the Bundler website and online documentation. + - We've created a solid base for Bundler 2.0. + - We prototyped a new plugin system. In addition, the Bundler Core team has spent a lot of time focusing on the development experience of bundler itself. The bundler codebase is over five -years old, and contains code from over 400 contributors. That can make it rather -daunting to start contributing, and also makes it hard to ensure that all of the -code in bundler is up to the same standards (and is fit to last for the next -five years!). In order to make things more consistent, we've introduced RuboCop -(and thus a style guide) to bundler, have instituted a build bot to ensure that -`master` is never failing, and have decided to subject 100% of the new code -introduced to code review. This is a big step forward, and lets me confidently -say that this will be our best release yet! +years old, and contains code from over 400 contributors. That can make it +rather daunting to start contributing, and also makes it hard to ensure that +all of the code in bundler is up to the same standards (and is fit to last for +the next five years!). In order to make things more consistent, we've +introduced RuboCop (and thus a style guide), we've instituted a build bot to +ensure that `master` is never failing, and have decided to subject 100% of the +new code introduced to code review. This is a big step forward, and lets me +confidently say that this will be our best release yet! That out of the way, what's actually in this long-awaited release? @@ -35,8 +36,8 @@ That out of the way, what's actually in this long-awaited release? First up, we've combed through a few years worth of bundler issues, and have improved the error messaging for every single one of them. Our goal is to never -show the full 'issue report template', and instead present a friendly and -helpful error message when things go awry -- and we're now pretty close to that. +show an exception with a backtrace, and instead present a friendly and helpful +error message when things go awry -- and we're now pretty close to that. The dependency resolver has also seen a few updates. Continuing the theme of improved errors, version conflicts will now do a better job of reporting what @@ -44,10 +45,9 @@ versions of every gem have been activated, making it even easier to figure out the best way to resolve said conflict. Additionally, resolution has been sped up by over 25x in pathological cases. That's a pretty nice win. -Finally, we've laid the groundwork for being able to take into account -`required_ruby_version` when resolving -- once the new index is rolled out, if -you specify a ruby version in your Gemfile, bundler will make sure to only -resolve for compatible gemspecs. +Finally, we've laid the groundwork for resolving gems based on the current +version of Ruby. Once the new index is rolled out, Bundler will make sure to +choose gems whose `required_ruby_version` matches the Ruby you are running on. ### Bugfixes From c405b80951202d1cb6085442df3a40c6e7b5771c Mon Sep 17 00:00:00 2001 From: Samuel Giddins Date: Sat, 12 Dec 2015 18:17:56 -0800 Subject: [PATCH 06/10] Add v1.11 --- source/shared/_whats_new.haml | 3 +- source/v1.11/bundle_binstubs.haml | 18 ++ source/v1.11/bundle_check.haml | 23 ++ source/v1.11/bundle_clean.haml | 16 ++ source/v1.11/bundle_config.haml | 275 +++++++++++++++++++ source/v1.11/bundle_console.haml | 15 + source/v1.11/bundle_exec.haml | 26 ++ source/v1.11/bundle_gem.haml | 38 +++ source/v1.11/bundle_help.haml | 10 + source/v1.11/bundle_init.haml | 17 ++ source/v1.11/bundle_inject.haml | 18 ++ source/v1.11/bundle_install.haml | 122 +++++++++ source/v1.11/bundle_open.haml | 12 + source/v1.11/bundle_outdated.haml | 23 ++ source/v1.11/bundle_package.haml | 75 +++++ source/v1.11/bundle_platform.haml | 39 +++ source/v1.11/bundle_show.haml | 16 ++ source/v1.11/bundle_update.haml | 218 +++++++++++++++ source/v1.11/bundle_version.haml | 8 + source/v1.11/bundle_viz.haml | 27 ++ source/v1.11/bundler_setup.haml | 103 +++++++ source/v1.11/bundler_sharing.haml | 60 ++++ source/v1.11/bundler_workflow.haml | 198 +++++++++++++ source/v1.11/commands.haml | 124 +++++++++ source/v1.11/deploying.haml | 155 +++++++++++ source/v1.11/faq.haml | 167 +++++++++++ source/v1.11/gemfile.haml | 155 +++++++++++ source/v1.11/gemfile_ruby.haml | 44 +++ source/v1.11/git.haml | 192 +++++++++++++ source/v1.11/groups.haml | 137 +++++++++ source/v1.11/index.haml | 140 ++++++++++ source/v1.11/rails23.haml | 104 +++++++ source/v1.11/rails3.haml | 76 +++++ source/v1.11/rationale.haml | 427 +++++++++++++++++++++++++++++ source/v1.11/rubygems.haml | 51 ++++ source/v1.11/rubymotion.haml | 36 +++ source/v1.11/sinatra.haml | 28 ++ source/v1.11/updating_gems.haml | 116 ++++++++ source/v1.11/whats_new.haml | 39 +++ 39 files changed, 3350 insertions(+), 1 deletion(-) create mode 100644 source/v1.11/bundle_binstubs.haml create mode 100644 source/v1.11/bundle_check.haml create mode 100644 source/v1.11/bundle_clean.haml create mode 100644 source/v1.11/bundle_config.haml create mode 100644 source/v1.11/bundle_console.haml create mode 100644 source/v1.11/bundle_exec.haml create mode 100644 source/v1.11/bundle_gem.haml create mode 100644 source/v1.11/bundle_help.haml create mode 100644 source/v1.11/bundle_init.haml create mode 100644 source/v1.11/bundle_inject.haml create mode 100644 source/v1.11/bundle_install.haml create mode 100644 source/v1.11/bundle_open.haml create mode 100644 source/v1.11/bundle_outdated.haml create mode 100644 source/v1.11/bundle_package.haml create mode 100644 source/v1.11/bundle_platform.haml create mode 100644 source/v1.11/bundle_show.haml create mode 100644 source/v1.11/bundle_update.haml create mode 100644 source/v1.11/bundle_version.haml create mode 100644 source/v1.11/bundle_viz.haml create mode 100644 source/v1.11/bundler_setup.haml create mode 100644 source/v1.11/bundler_sharing.haml create mode 100644 source/v1.11/bundler_workflow.haml create mode 100644 source/v1.11/commands.haml create mode 100644 source/v1.11/deploying.haml create mode 100644 source/v1.11/faq.haml create mode 100644 source/v1.11/gemfile.haml create mode 100644 source/v1.11/gemfile_ruby.haml create mode 100644 source/v1.11/git.haml create mode 100644 source/v1.11/groups.haml create mode 100644 source/v1.11/index.haml create mode 100644 source/v1.11/rails23.haml create mode 100644 source/v1.11/rails3.haml create mode 100644 source/v1.11/rationale.haml create mode 100644 source/v1.11/rubygems.haml create mode 100644 source/v1.11/rubymotion.haml create mode 100644 source/v1.11/sinatra.haml create mode 100644 source/v1.11/updating_gems.haml create mode 100644 source/v1.11/whats_new.haml diff --git a/source/shared/_whats_new.haml b/source/shared/_whats_new.haml index 7bc33dc81c..fa867a8836 100644 --- a/source/shared/_whats_new.haml +++ b/source/shared/_whats_new.haml @@ -1,6 +1,7 @@ %h1 What's New in each Release .buttons - = link_to 'v1.10', '/v1.10/whats_new.html' + = link_to 'v1.11', '/v1.11/whats_new.html' + = link_to 'v1.10', '/v1.10/whats_new.html#version110' = link_to 'v1.9', '/v1.9/whats_new.html#version19' = link_to 'v1.8', '/v1.8/whats_new.html#version18' = link_to 'v1.7', '/v1.7/whats_new.html#version17' diff --git a/source/v1.11/bundle_binstubs.haml b/source/v1.11/bundle_binstubs.haml new file mode 100644 index 0000000000..1bd4e824ab --- /dev/null +++ b/source/v1.11/bundle_binstubs.haml @@ -0,0 +1,18 @@ +%h2 bundle binstubs + +.contents + .bullet + .description + Installs the binstubs of the listed gem + :code + $ bundle binstubs [GEM] [--force] [--path=PATH] + .notes + %p + Options: + %p + --force: Overwrite existing binstubs if they exist. + %p + --path: Binstub destination directory (default bin) + .description + Generate binstubs for executables in [GEM]. Binstubs are put into bin, + or the --binstubs directory if one has been set. diff --git a/source/v1.11/bundle_check.haml b/source/v1.11/bundle_check.haml new file mode 100644 index 0000000000..606f48b541 --- /dev/null +++ b/source/v1.11/bundle_check.haml @@ -0,0 +1,23 @@ +%h2 bundle check + +.contents + .bullet + .description + Checks if the dependencies listed in Gemfile are satisfied by currently installed gems + :code + $ bundle check [--dry-run] [--gemfile=FILE] [--path=PATH] + .notes + %p + Options: + %p + --dry-run: Locks the Gemfile. + %p + --gemfile: Use the specified gemfile instead of Gemfile. + %p + --path: Specify a different path than the system default + ($BUNDLE_PATH or $GEM_HOME). Bundler will remember this value for future + installs on this machine. + .description + Check searches the local machine for each of the gems requested in the Gemfile. If + all gems are found, Bundler prints a success message and exits with a status of 0. + If not, the first missing gem is listed and Bundler exits status 1. diff --git a/source/v1.11/bundle_clean.haml b/source/v1.11/bundle_clean.haml new file mode 100644 index 0000000000..9ca8ef3993 --- /dev/null +++ b/source/v1.11/bundle_clean.haml @@ -0,0 +1,16 @@ +%h2 bundle clean + +.contents + .bullet + .description + Cleans up unused gems in your bundler directory + :code + $ bundle clean [--dry-run] [--force] + .notes + %p + Options: + %p + --dry-run: Only print out changes, do not actually clean + gems + %p + --force: Forces clean even if --path is set diff --git a/source/v1.11/bundle_config.haml b/source/v1.11/bundle_config.haml new file mode 100644 index 0000000000..ae17158ca1 --- /dev/null +++ b/source/v1.11/bundle_config.haml @@ -0,0 +1,275 @@ +%h2 bundle config + +.contents + .bullet + .description + Retrieve or set a configuration value + :code + $ bundle config [NAME [VALUE]] [--local] [--global] [--delete] + .notes + %p + Options: + %p + --local: Get/set local configuration + %p + --global: Get/set global configuration + %p + --delete: Delete NAME value + .description + %p + Retrieves or sets a configuration value. If only parameter is provided, + retrieve the value. If two parameters are provided, replace the existing + value with the newly provided one. + %p + By default, setting a configuration value sets it for all projects on + the machine. + %p + If a global setting is superceded by local configuration, this command + will show the current value, as well as any superceded values and where + they were specified. + + .bullet#config + .description + Get your bundle configuration. + .how + :code + $ bundle config + .notes + Executing bundle config with no parameters will print a + list of all bundler configuration for the current bundle, and where + that configuration was set. + + .bullet#get + .description + Get your bundle configuration for NAME variable. + .how + :code + $ bundle config NAME + .notes + Will print the value of that configuration setting for + NAME, and where it was set. Will print both local and + global configuration. + + .bullet#set + .description + Set your bundle configuration for NAME variable to + VALUE. + .how + :code + $ bundle config NAME VALUE + .notes + Will set NAME to VALUE for all bundles + executed as the current user (i.e. global setting). The configuration + will be stored in ~/.bundle/config. If NAME + already is set, NAME will be overridden and user will be + warned. + + .bullet#global + .description + Set your bundle global/user configuration for NAME variable + to VALUE. + .how + :code + $ bundle config --global NAME VALUE + .notes + Works the same as the command above. + + .bullet#local + .description + Set your bundle local configuration for NAME variable to + VALUE. + .how + :code + $ bundle config --local NAME VALUE + .notes + Works the same as the two command above but for the local application. + The configuration will be stored in app/.bundle/config. + + .bullet#delete + .description + Delete the configuration for NAME in both local and global sources. + .how + :code + $ bundle config --delete NAME + .notes + Will delete the configuration for NAME variable in both local and global sources. Not compatible with --global or --local flag. + +%h2 Build options +.contents + .bullet#build_options + .description + %p + You can use bundle config to give bundler the flags to + pass to the gem installer every time bundler tries to install a + particular gem. + + %p + A very common example, the mysql gem, requires Snow + Leopard users to pass configuration flags to gem install + to specify where to find the mysql_config executable. + + .how + :code + $ gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config + + %p + Since the specific location of that executable can change from machine + to machine, you can specify these flags on a per-machine basis. + + .how + :code + $ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config + %p + After running this command, every time bundler needs to install the + mysql gem, it will pass along the flags you specified. + + +%h2 Configuration keys +.contents + .bullet#configuration_keys + .description + %p + Configuration keys in bundler have two forms: the canonical form and + the environment variable form. + + %p + For instance, passing the --without flag to + bundle install prevents Bundler from installing + certain groups specified in the Gemfile. Bundler persists + this value in app/.bundle/config so that calls to + Bundler.setup do not try to find gems from the + Gemfile that you didn't install. Additionally, subsequent + calls to bundle install remember this setting and + skip those groups. + + %p + The canonical form of this configuration is "without". To + convert the canonical form to the environment variable form, capitalize + it, and prepend BUNDLE_. The environment variable form of + "without" is BUNDLE_WITHOUT. + +%h2 List of available keys +.contents + .bullet#available_keys + .description + %p + The following is a list of all configuration keys and their purpose. + You can learn more about their operation in + bundle install. + %ul + %li + auto_install (1): Setting auto_install config + to 1 or any other truthy value will enable automatic installing of gems + instead of raising an error. This behavior applies to the following + commands: show, binstubs, + outdated, exec, open, + console, license, clean. + %li + path (BUNDLE_PATH): The location on disk + to install gems. Defaults to $GEM_HOME in development + and vendor/bundle when --deployment is used. + %li + frozen (BUNDLE_FROZEN): Disallow changes to + the Gemfile. Defaults to true when + --deployment is used. + %li + without (BUNDLE_WITHOUT): A + :-separated list of groups whose gems bundler should not + installer + %li + bin (BUNDLE_BIN): Install executables from + gems in the bundle to the specified directory. Defaults to + false. + %li + gemfile (BUNDLE_GEMFILE): The name of the + file that bundler should use as the Gemfile. This location + of this file also sets the root of the project, which is used to + resolve relative paths in the Gemfile, among other things. + By default, bundler will search up from the current working directory + until it finds a Gemfile. + %li + ssl_ca_cert (BUNDLE_SSL_CA_CERT): + Path to a designated CA certificate file or folder containing multiple + certificates for trusted CAs in PEM format. + %li + ssl_client_cert (BUNDLE_SSL_CLIENT_CERT): + Path to a designated file containing a X.509 client certificate + and key in PEM format. + %li + cache_path (BUNDLE_CACHE_PATH): The directory + that bundler will place cached gems in when running bundle + package and that bundler will look in when installing with the + --deployment option. + %li + disable_multisource (BUNDLE_DISABLE_MULTISOURCE): + When set, Gemfiles containing multiple sources will produce an error + instead of a warning. Use bundle config --delete + disable_multisource to unset. + + %p + In general, you should set these settings per-application by using the + applicable flag to the bundle install or bundle + package command. + + %p + You can set them globally either via environment variables or + bundle config, whichever is preferable for your setup. If + you use both, environment variables will take preference over global + settings. + +%h2 Local git repositories +.contents + .bullet#local_git_repos + .description + %p + Bundler also allows you to work against a git repository locally + instead of using the remote version. This can be achieved by setting + up a local override: + + :code + $ bundle config local.GEM_NAME /path/to/local/git/repository + + %p + For example, in order to use a local Rack repository, a developer + could call: + + :code + $ bundle config local.rack ~/Work/git/rack + + %p + Now instead of checking out the remote git repository, the local + override will be used. Similar to a path source, every time the local + git repository change, changes will be automatically picked up by + Bundler. This means a commit in the local git repo will update the + revision in the Gemfile.lock to the local git repo + revision. This requires the same attention as git submodules. Before + pushing to the remote, you need to ensure the local override was + pushed, otherwise you may point to a commit that only exists in your + local machine. + + %p + Bundler does many checks to ensure a developer won't work with + invalid references. Particularly, we force a developer to specify a + branch in the Gemfile in order to use this feature. If the + branch specified in the `Gemfile` and the current branch in the local + git repository do not match, Bundler will abort. This ensures that a + developer is always working against the correct branches, and prevents + accidental locking to a different branch. + + %p + Finally, Bundler also ensures that the current revision in the + Gemfile.lock exists in the local git repository. By doing + this, Bundler forces you to fetch the latest changes in the remotes. + +%h2 Gem Source Mirrors +.contents + .bullet#gem-source-mirrors + .description + %p + If your environment contains a local mirror of the rubygems.org server, + use the mirror.URL configuration option to supply the URL + of the mirror. At that point, Bundler will download gems and gemspecs + from that mirror instead of the source listed in the Gemfile. + + :code + $ bundle config mirror.https://rubygems.org https://localgems.lan diff --git a/source/v1.11/bundle_console.haml b/source/v1.11/bundle_console.haml new file mode 100644 index 0000000000..9efd8a0527 --- /dev/null +++ b/source/v1.11/bundle_console.haml @@ -0,0 +1,15 @@ +%h2 bundle console + +.contents + .bullet + .description + Start an interactive Ruby console session in the context of the current bundle + :code + $ bundle console [GROUP] + + .description + bundle console uses irb by default. Alternatives like Pry and Ripl can be used with bundle console by adjusting the console Bundler setting. Also make sure that pry or ripl is in your Gemfile. + :code + $ bundle config console pry + $ bundle console + [1] pry(main)> diff --git a/source/v1.11/bundle_exec.haml b/source/v1.11/bundle_exec.haml new file mode 100644 index 0000000000..3f8de13cd1 --- /dev/null +++ b/source/v1.11/bundle_exec.haml @@ -0,0 +1,26 @@ +%h2 bundle exec + +.contents + .bullet + .description + Run the command in context of the bundle + :code + $ bundle exec [--keep-file-descriptors] + .notes + %p + Options: + %p + --keep-file-descriptors: For Ruby versions less than 2.0, + keeps non-standard file descriptors on Kernel#exec + + .description + This command executes the command, making all gems specified in the + Gemfile(5) available to require in Ruby programs. + + Essentially, if you would normally have run something like + rspec spec/my_spec.rb, and you want to use the gems specified + in the Gemfile and installed via bundle install, you + should run bundle exec rspec spec/my_spec.rb. + + Note that bundle exec does not require that an executable is + available on your shell's $PATH. diff --git a/source/v1.11/bundle_gem.haml b/source/v1.11/bundle_gem.haml new file mode 100644 index 0000000000..ae8406a0fa --- /dev/null +++ b/source/v1.11/bundle_gem.haml @@ -0,0 +1,38 @@ +%h2 bundle gem + +.contents + .bullet + .description + Creates a skeleton for creating a rubygem + :code + $ bundle gem GEM [--bin or -b] [--test=TESTFRAMEWORK] [--edit=TEXTEDITOR] [--ext] + .notes + %p + Options: + %p + --bin or -b: Generate a binary for your library. + %p + --coc: Generate a code of conduct file. + %p + --edit: Open generated gemspec in the specified editor (defaults to $EDITOR or $BUNDLER_EDITOR) + %p + --ext: Generate a skeleton for a C-extension. + %p + --mit: Generate an MIT license file. + %p + --test: Generate a test directory for your library: + rspec is the default, but minitest is also supported. + .notes + %p + When run for the first time, bundle gem will ask for your preferences regarding test framework, code of conduct, and MIT license. These preferences will be stored in ~/.bundle/config for future runs. + .bullet + .description + The generated project will contain all the necessary boilerplate, including a README and a gemspec template. Also included will be a Rakefile with tasks suitable for gem development: + .how + :code + $ rake -T + rake build # Build GEM-0.1.0.gem into the pkg directory + rake install # Build and install GEM-0.1.0.gem into system gems + rake install:local # Build and install GEM-0.1.0.gem into system gems without network access + rake release # Create tag v0.1.0 and build and push GEM-0.1.0.gem to Rubygems + rake test # Run tests diff --git a/source/v1.11/bundle_help.haml b/source/v1.11/bundle_help.haml new file mode 100644 index 0000000000..fd09a4b50a --- /dev/null +++ b/source/v1.11/bundle_help.haml @@ -0,0 +1,10 @@ +%h2 bundle help + +.contents + .bullet + .description + Displays detailed help for each subcommand on your command line + :code + $ bundle help + .notes + #{ link_to 'View the same man pages here', './man/bundle.1.html'} diff --git a/source/v1.11/bundle_init.haml b/source/v1.11/bundle_init.haml new file mode 100644 index 0000000000..18e7d7bd3b --- /dev/null +++ b/source/v1.11/bundle_init.haml @@ -0,0 +1,17 @@ +%h2 bundle init + +.contents + .bullet + .description + Generates a Gemfile into the current working directory + :code + $ bundle init [--gemspec=FILE] + .notes + %p + Options: + %p + --gemspec: Use the specified .gemspec to create the Gemfile + .description + Init generates a default Gemfile in the current working directory. When adding a + Gemfile to a gem with a gemspec, the --gemspec option will automatically add each + dependency listed in the gemspec file to the newly created Gemfile. diff --git a/source/v1.11/bundle_inject.haml b/source/v1.11/bundle_inject.haml new file mode 100644 index 0000000000..51fd112a33 --- /dev/null +++ b/source/v1.11/bundle_inject.haml @@ -0,0 +1,18 @@ +%h2 bundle inject + +.contents + .bullet + .description + Add the named gem(s), with version requirements, to the resolved Gemfile + :code + $ bundle inject [GEM] [VERSION] + + .bullet + .description + When injecting a gem, it adds it to both your Gemfile and Gemfile.lock if + it doesn't yet exist in them. Example below: + :code + $ bundle install + + $ bundle inject 'rack' '> 0' + # Injects rack gem greater than version 0 in your Gemfile and Gemfile.lock diff --git a/source/v1.11/bundle_install.haml b/source/v1.11/bundle_install.haml new file mode 100644 index 0000000000..ad8958ec21 --- /dev/null +++ b/source/v1.11/bundle_install.haml @@ -0,0 +1,122 @@ +%h2 bundle install + +.contents + .bullet + .description + Make sure all dependencies in your Gemfile are available to your application. + :code + $ bundle install [--binstubs=PATH] [--clean] [--deployment] [--frozen] + [--full-index] [--gemfile=FILE] [--local] [--no-cache] + [--no-prune] [--path=PATH] [--quiet] [--shebang=STRING] + [--standalone[=GROUP [GROUP...]] [--system] + [--without=GROUP[ GROUP...]] [--retry=NUMBER] + [--trust-policy=SECURITYLEVEL] + .notes + %p + Options: + %p + --binstubs: Generate bin stubs for bundled gems to ./bin + %p + --clean: Run bundle clean automatically after install + %p + --deployment: Install using defaults tuned for deployment and CI environments + %p + --frozen: Do not allow the Gemfile.lock to be updated after this install + %p + --full-index: Use the rubygems modern index instead of the API endpoint + %p + --gemfile: Use the specified gemfile instead of Gemfile + %p + --jobs: Install gems using parallel workers. + %p + --local: Do not attempt to fetch gems remotely and use the gem cache instead + %p + --no-cache: Don't update the existing gem cache. + %p + --no-prune: Don't remove stale gems from the cache. + %p + --path: Specify a different path than the system default ($BUNDLE_PATH or $GEM_HOME). Bundler will remember this value for future installs on this machine + %p + --quiet: Only output warnings and errors. + %p + --retry: Retry network and git requests that have failed. + %p + --shebang: Specify a different shebang executable name than the default (usually 'ruby') + %p + --standalone: Make a bundle that can work without the Bundler runtime + %p + --system: Install to the system location ($BUNDLE_PATH or $GEM_HOME) even if the bundle was previously installed somewhere else for this application + %p + --trust-policy: Sets level of security when dealing with signed gems. Accepts `LowSecurity`, `MediumSecurity` and `HighSecurity` as values. + %p + --without: Exclude gems that are part of the specified named group. + .notes + %p + Gems will be installed to your default system location for gems. If your + system gems are stored in a root-owned location (such as in Mac OSX), + bundle will ask for your root password to install them there. + %p + While installing gems, Bundler will check vendor/cache and then + your system's gems. If a gem isn't cached or installed, Bundler will try to + install it from the sources you have declared in your Gemfile. + %p + The --system option is the default. Pass it to switch back after + using the --path option as described below. + + .bullet#path + .description + Install your dependencies, even gems that are already installed + to your system gems, to a location other than your system's gem + repository. In this case, install them to vendor/bundle. + .how + :code + $ bundle install --path vendor/bundle + .notes + Further bundle commands or calls to Bundler.setup or + Bundler.require will remember this location. + = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + = link_to 'Learn More: Bundler.require', './groups.html' + + .bullet#without + .description + Install all dependencies except those in groups that are explicitly excluded. + :code + $ bundle install --without development test + = link_to 'Learn More: Groups', './groups.html' + + .bullet#deployment + .description + Install all dependencies onto a production or CI server. + Do not use this flag on a development machine. + :code + $ bundle install --deployment + .notes + %p + The --deployment flag activates a number of deployment- and + CI-friendly conventions: + + %ul + %li + Isolate all gems into vendor/bundle + (equivalent to --path vendor/bundle) + %li + Require an up-to-date Gemfile.lock + (equivalent to --frozen) + %li Disable ANSI color output + %li + If bundle package was run, do not fetch gems + from rubygems.org. Instead, only use gems in the checked + in vendor/cache + = link_to 'Learn More: Deploying', './deploying.html' + + .bullet#jobs + .description + Install gems parallely by starting the number of workers specificed. + :code + $ bundle install --jobs 4 + + .bullet#retry + .description + Retry failed network or git requests. + :code + $ bundle install --retry 3 diff --git a/source/v1.11/bundle_open.haml b/source/v1.11/bundle_open.haml new file mode 100644 index 0000000000..bcdcc0b01e --- /dev/null +++ b/source/v1.11/bundle_open.haml @@ -0,0 +1,12 @@ +%h2 bundle open + +.contents + .bullet + .description + Opens the source directory of the given bundled gem + :code + $ bundle open GEM + .description + %p + Opens the source directory of the provided GEM in your editor. For this to + work the `EDITOR` or `BUNDLER_EDITOR` environment variable has to be set. diff --git a/source/v1.11/bundle_outdated.haml b/source/v1.11/bundle_outdated.haml new file mode 100644 index 0000000000..ccfd040f56 --- /dev/null +++ b/source/v1.11/bundle_outdated.haml @@ -0,0 +1,23 @@ +%h2 bundle outdated + +.contents + .bullet + .description + List installed gems with newer versions available + :code + $ bundle outdated [GEM] [--local] [--pre] [--source] [--strict] + .notes + %p + Options: + %p + --local: Do not attempt to fetch gems remotely and use the gem cache instead + %p + --pre: Check for newer pre-release gems + %p + --source: Check against a specific source + %p + --strict: Display outdated gems that match the dependency requirements. + .description + Outdated lists the names and versions of gems that have a newer version available + in the given source. Calling outdated with [GEM [GEM]] will only check for newer + versions of the given gems. By default, available prerelease gems will be ignored. diff --git a/source/v1.11/bundle_package.haml b/source/v1.11/bundle_package.haml new file mode 100644 index 0000000000..bf0d402b50 --- /dev/null +++ b/source/v1.11/bundle_package.haml @@ -0,0 +1,75 @@ +%h2 bundle package + +.contents + .bullet + .description + Locks and then caches the gems into ./vendor/cache. + :code + $ bundle package [--all] [--all-platforms] [--gemfile=GEMFILE] [--no-prune] + [--path=PATH] [--quiet] + .notes + %p + Options: + %p + --all: package :git, :path, and .gem dependencies. Once used, the --all option will be remembered. + %p + --all-platforms: package dependencies for all known platforms, not only the one that bundle package is run on. This option will be remembered in your local Bundler configuration. + %p + --gemfile: Use the specified gemfile instead of Gemfile. + %p + --no-install: Don't actually install the gems, just package. + %p + --no-prune: Don't remove stale gems from the cache. + %p + --path: Specify a different path than the system default. + %p + --quiet: Only output warnings and errors. + .description + %p + The package command will copy the .gem files for your gems in the + bundle into ./vendor/cache. Afterward, when you run bundle install, Bundler will use the gems in the cache in preference to the ones on rubygems.org. + + %p + Additionally, if you then check that directory into your source control repository, others who check out your source will be able to install the bundle without having to download any additional gems. + + .bullet + .description + Lock and cache gems from RubyGems into ./vendor/cache. + + .how + :code + $ bundle package + + .notes + %p + By default, if you simply run bundle install after running + bundle package, Bundler will still connect to rubygems.org to check + whether a platform-specific gem exists for any of the gems in vendor/cache. + + %p + This behavior can be avoided by instead running bundle install --local. + Note that this requires you to have the correctly platformed version for all of your gems + already cached. The easiest way to achieve this is to run bundle package + on an identical machine and then check in those vendored gems. + + .bullet#no-prune + .description + Lock and cache gems from RubyGems into ./vendor/cache, and don't remove any stale gems from the existing cache. + + .how + :code + $ bundle package --no-prune + + .bullet#all + .description + Lock and cache all gems into ./vendor/cache, including :git, :path, and .gem dependencies. + + .how + :code + $ bundle package --all + .notes + %p + Once used, the --all option will be remembered. + + %p + This will be the default on Bundler 2.0. diff --git a/source/v1.11/bundle_platform.haml b/source/v1.11/bundle_platform.haml new file mode 100644 index 0000000000..f77674bfe9 --- /dev/null +++ b/source/v1.11/bundle_platform.haml @@ -0,0 +1,39 @@ +%h2 bundle platform + +.contents + .bullet + .description + Displays platform compatibility information + :code + $ bundle platform [--ruby] + .notes + %p + Options: + %p + --ruby: only display ruby related platform information + + .bullet + .description + When not passed any options, platform will display information from your Gemfile, Gemfile.lock, and Ruby VM about your platform. You'll see output like the following: + :code + $ bundle platform + Your platform is: x86_64-linux + + Your app has gems that work on these platforms: + * ruby + + Your Gemfile specifies a Ruby version requirement: + * ruby 1.9.3 + + Your current platform satisfies the Ruby version requirement. + .description + When the ruby directive doesn't match the running Ruby VM, it will tell you what part does not. + :code + Your Ruby version is 1.9.3, but your Gemfile specified 1.8.7 + + .bullet#ruby + .description + When using the --ruby flag, it will just display the ruby directive information, so you don't have to parse it from the Gemfile. + :code + $ bundle platform --ruby + ruby 1.9.3 (jruby 1.6.7) diff --git a/source/v1.11/bundle_show.haml b/source/v1.11/bundle_show.haml new file mode 100644 index 0000000000..72080427ed --- /dev/null +++ b/source/v1.11/bundle_show.haml @@ -0,0 +1,16 @@ +%h2 bundle show + +.contents + .bullet + .description + Shows all gems that are part of the bundle, or the path to a given gem + :code + $ bundle show [GEM] [--paths] + .notes + %p + Options: + %p + --paths: List the paths of all gems that are required by your Gemfile. + .description + Show lists the names and versions of all gems that are required by your Gemfile. + Calling show with [GEM] will list the exact location of that gem on your machine. diff --git a/source/v1.11/bundle_update.haml b/source/v1.11/bundle_update.haml new file mode 100644 index 0000000000..c8f0cf7898 --- /dev/null +++ b/source/v1.11/bundle_update.haml @@ -0,0 +1,218 @@ +%h2 bundle update + +.contents + .bullet + .description + Update the current environment + + :code + $ bundle update [GEM] [--full-index] [--group=GROUP] [--jobs=NUMBER] [--local] + [--quiet] [--source=SOURCE] + .notes + %p + Options: + %p + --full-index: Use the rubygems modern index instead of + the API endpoint + %p + --group: Update one or more gem groups + %p + --jobs: Specify the number of jobs to run in parallel + %p + --local: Do not attempt to fetch gems remotely and use + the gem cache instead + %p + --quiet: Only output warnings and errors. + %p + --source: Update a specific source (and all gems + associated with it) + + .description + %p + Update the gems specified (all gems, if none are specified), ignoring + the previously installed gems specified in the Gemfile.lock. + In general, you should use bundle install to install the + same exact gems and versions across machines. + + %p + You would use bundle update to explicitly update the + version of a gem. + + .bullet + .description + Update the current environment. + .how + :code + $ bundle update + .notes + If you run bundle update with no parameters, bundler will + ignore any previously installed gems and resolve all dependencies again + based on the latest versions of all gems available in the sources. + + .bullet#source + .description + Update a specific source (and all gems associated with it) + .how + :code + $ bundle update --source=SOURCE + .notes + The name of a :git or :path source used in the + Gemfile. For instance, with a :git source of + http://github.com/rails/rails.git, you would call + bundle update --source rails. + +%h2 Update all gems +.contents + .bullet#update_all_extended + .description + %p + If you run bundle update with no parameters, bundler will + ignore any previously installed gems and resolve all dependencies again + based on the latest versions of all gems available in the sources. + + %p + Consider the following Gemfile: + + :code + # lang: ruby + source 'https://rubygems.org' + gem 'rails', '3.0.0.rc' + gem 'nokogiri' + %p + When you run bundle install the first time, bundler will + resolve all of the dependencies, all the way down, and install what you + need: + :code + Fetching source index for https://rubygems.org/ + Installing rake (0.8.7) + Installing abstract (1.0.0) + Installing activesupport (3.0.0.rc) + Installing builder (2.1.2) + Installing i18n (0.4.1) + Installing activemodel (3.0.0.rc) + Installing erubis (2.6.6) + Installing rack (1.2.1) + Installing rack-mount (0.6.9) + Installing rack-test (0.5.4) + Installing tzinfo (0.3.22) + Installing actionpack (3.0.0.rc) + Installing mime-types (1.16) + Installing polyglot (0.3.1) + Installing treetop (1.4.8) + Installing mail (2.2.5) + Installing actionmailer (3.0.0.rc) + Installing arel (0.4.0) + Installing activerecord (3.0.0.rc) + Installing activeresource (3.0.0.rc) + Installing bundler (1.0.0.rc.3) + Installing nokogiri (1.4.3.1) with native extensions + Installing thor (0.14.0) + Installing railties (3.0.0.rc) + Installing rails (3.0.0.rc) + + Your bundle is complete! Use `bundle show [gemname]` to see where a + bundled gem is installed. + %p + As you can see, even though you have just two gems in the + Gemfile, your application actually needs 25 different gems + in order to run. Bundler remembers the exact versions it installed in + Gemfile.lock. The next time you run + bundle install, bundler skips the dependency resolution and + installs the same gems as it installed last time. + + %p + After checking in the Gemfile.lock into version control and + cloning it on another machine, running bundle install will + _still_ install the gems that you installed last time. You don't need to + worry that a new release of erubis or mail + changes the gems you use. + + %p + However, from time to time, you might want to update the gems you are + using to the newest versions that still match the gems in your + Gemfile. + + %p + To do this, run bundle update, which will ignore the + Gemfile.lock, and resolve all the dependencies again. Keep + in mind that this process can result in a significantly different set + of the 25 gems, based on the requirements of new gems that the gem + authors released since the last time you ran bundle update. + +%h2 Update a list of gems. +.contents + .bullet#update_list_of_gems + .description + %p + Sometimes, you want to update a single gem in the Gemfile, + and leave the rest of the gems that you specified locked to the + versions in the Gemfile.lock. + + %p + For instance, in the scenario above, imagine that + nokogiri releases version 1.4.4, and you want + to update it _without_ updating Rails and all of its dependencies. To + do this, run + + :code + bundle update nokogiri + + %p + Bundler will update nokogiri and any of its dependencies, + but leave alone Rails and its dependencies. + +%h2 Overlapping dependencies +.contents + .bullet#overlapping_dependencies + .description + %p + Sometimes, multiple gems declared in your Gemfile are + satisfied by the same second-level dependency. For instance, consider the + case of thin and rack-perftools-profiler. + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'thin' + gem 'rack-perftools-profiler' + + %p + The thin gem depends on rack >= 1.0, while + rack-perftools-profiler depends on rack ~> 1.0. + If you run bundle install, you get: + + :code + Fetching source index for https://rubygems.org/ + Installing daemons (1.1.0) + Installing eventmachine (0.12.10) with native extensions + Installing open4 (1.0.1) + Installing perftools.rb (0.4.7) with native extensions + Installing rack (1.2.1) + Installing rack-perftools_profiler (0.0.2) + Installing thin (1.2.7) with native extensions + Using bundler (1.0.0.rc.3) + + %p + In this case, the two gems have their own set of dependencies, but they + share rack in common. If you run bundle update + thin, bundler will update daemons, + eventmachine and rack, which are dependencies + of thin, but not open4 or + perftools.rb, which are dependencies of + rack-perftools_profiler. Note that + bundle update thin will update rack even though + it's _also_ a dependency of rack-perftools_profiler. + + %p + In short, when you update a gem using + bundle update, bundler will update all dependencies of that + gem, including those that are also dependencies of another gem. + + %p + In this scenario, updating the thin version manually in the + Gemfile, and then running bundle install will + only update daemons and eventmachine, but not + rack. + -# For more information, see the CONSERVATIVE UPDATING + -#section of bundle install. diff --git a/source/v1.11/bundle_version.haml b/source/v1.11/bundle_version.haml new file mode 100644 index 0000000000..54c1e71dc1 --- /dev/null +++ b/source/v1.11/bundle_version.haml @@ -0,0 +1,8 @@ +%h2 bundle version + +.contents + .bullet + .description + Prints the bundler's version information + :code + $ bundle version diff --git a/source/v1.11/bundle_viz.haml b/source/v1.11/bundle_viz.haml new file mode 100644 index 0000000000..f7b4cafb26 --- /dev/null +++ b/source/v1.11/bundle_viz.haml @@ -0,0 +1,27 @@ +%h2 bundle viz + +.contents + .bullet + .description + Generates a visual dependency graph + :code + $ bundle viz [--file=FILE] [--format=FORMAT] [--requirements] [--version] + [--without=GROUP GROUP] + .notes + %p + Options: + %p + --file or -f: The name to use for the generated file. see format option + %p + --format or -F: This is output format option. Supported format is png, jpg, svg, dot ... + %p + --requirements or -r: Set to show the version of each required dependency. + %p + --version or -v: Set to show each gem version. + %p + --without: Exclude gems that are part of the specified named group. + = link_to 'Learn More: Groups', './groups.html' + .description + Viz generates a PNG file of the current Gemfile as a dependency graph. + Viz requires the ruby-graphviz gem (and its dependencies). + The associated gems must also be installed via 'bundle install'. diff --git a/source/v1.11/bundler_setup.haml b/source/v1.11/bundler_setup.haml new file mode 100644 index 0000000000..82276cb26f --- /dev/null +++ b/source/v1.11/bundler_setup.haml @@ -0,0 +1,103 @@ +%h2 Bundler.setup + +.contents + .bullet + .description + Configure the load path so all dependencies in + your Gemfile can be required + :code + # lang: ruby + require 'rubygems' + require 'bundler/setup' + require 'nokogiri' + + .bullet + .description + Only add gems from specified groups to the + load path. If you want the gems in the + default group, make sure to include it + :code + # lang: ruby + require 'rubygems' + require 'bundler' + Bundler.setup(:default, :ci) + require 'nokogiri' + = link_to 'Learn More: Groups', './groups.html' + +%h2 Compatibility + +.contents + .bullet + .description + Ruby 2.0 and RubyGems 2.0 both require Bundler 1.3 or later. If you have questions about compatibility between Bundler and your system, please check the compatibility list. + = link_to 'Learn More: Compatibility', '/compatibility.html' + + %h2#setting-up-your-application-to-use-bundler + Setting Up Your Application to Use Bundler + + .bullet + .description + Bundler makes sure that Ruby can find all of the gems in the Gemfile + (and all of their dependencies). If your app is a Rails 3 app, your default application + already has the code necessary to invoke bundler. If it is a Rails 2.3 app, please see: + Setting up Bundler in Rails 2.3 + + .bullet + .description + For another kind of application (such as a Sinatra application), you will need to set up + bundler before trying to require any gems. At the top of the first file that your + application loads (for Sinatra, the file that calls require 'sinatra'), put + the following code: + + :code + # lang: ruby + require 'rubygems' + require 'bundler/setup' + + .bullet + .description + This will automatically discover your Gemfile, and make all of the gems in + your Gemfile available to Ruby (in technical terms, it puts the gems "on the + load path"). You can think of it as an adding some extra powers to require + 'rubygems'. + + .bullet + .description + Now that your code is available to Ruby, you can require the gems that you need. For + instance, you can require 'sinatra'. If you have a lot of dependencies, you + might want to say "require all of the gems in my Gemfile". To do this, put + the following code immediately following require 'bundler/setup': + + :code + # lang: ruby + Bundler.require(:default) + + For our example Gemfile, this line is exactly equivalent to: + + :code + # lang: ruby + require 'rails' + require 'rack-cache' + require 'nokogiri' + + .bullet + .description + Astute readers will notice that the correct way to require the rack-cache + gem is require 'rack/cache', not require 'rack-cache'. To tell + bundler to use require 'rack/cache', update your Gemfile: + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'rails', '3.0.0.rc' + gem 'rack-cache', :require => 'rack/cache' + gem 'nokogiri', '~> 1.4.2' + + .bullet + .description + For such a small Gemfile, we'd advise you to skip + Bundler.require and just require the gems by hand (especially given the + need to put in a :require directive in the Gemfile). For much + larger Gemfiles, using Bundler.require allows you to skip + repeating a large stack of requirements. diff --git a/source/v1.11/bundler_sharing.haml b/source/v1.11/bundler_sharing.haml new file mode 100644 index 0000000000..8734945302 --- /dev/null +++ b/source/v1.11/bundler_sharing.haml @@ -0,0 +1,60 @@ +%h2#sharing + Sharing +.contents + .bullet + .description + %h3#checking-your-code-into-version-control + Checking Your Code into Version Control + + %p + After developing your application for a while, check in the application together with the + Gemfile and Gemfile.lock snapshot. Now, your repository has a + record of the exact versions of all of the gems that you used the last time you know for + sure that the application worked. Keep in mind that while your Gemfile + lists only three gems (with varying degrees of version strictness), your application + depends on dozens of gems, once you take into consideration all of the implicit + requirements of the gems you depend on. + + %p.description + This is important: the Gemfile.lock makes your application a single + package of both your own code and the third-party code it ran the last time you know for + sure that everything worked. Specifying exact versions of the third-party code + you depend on in your Gemfile would not provide the same guarantee, because + gems usually declare a range of versions for their dependencies. + + %p.description + The next time you run bundle install on the same machine, bundler will see + that it already has all of the dependencies you need, and skip the installation process. + + %p.description + Do not check in the .bundle directory, or any of the files inside it. Those + files are specific to each particular machine, and are used to persist installation options + between runs of the bundle install command. + + %p.description + If you have run bundle pack, the gems (although not the git gems) required + by your bundle will be downloaded into vendor/cache. Bundler can run without + connecting to the internet (or the RubyGems server) if all the gems you need are present + in that folder and checked in to your source control. This is an optional + step, and not recommended, due to the increase in size of your source control repository. + + .bullet + %h3#sharing-your-application-with-other-developers + Sharing Your Application With Other Developers + + %p.description + When your co-developers (or you on another machine) check out your code, it will come + with the exact versions of all the third-party code your application used on the machine + that you last developed on (in the Gemfile.lock). When **they** run + bundle install, bundler will find the Gemfile.lock and skip + the dependency resolution step. Instead, it will install all of the same gems that you + used on the original machine. + + %p.description + In other words, you don't have to guess which versions of the dependencies you should + install. In the example we've been using, even though rack-cache declares a + dependency on rack >= 0.4, we know for sure it works with rack + 1.2.1. Even if the Rack team releases rack 1.2.2, bundler will + always install 1.2.1, the exact version of the gem that we know works. This + relieves a large maintenance burden from application developers, because all machines + always run the exact same third-party code. diff --git a/source/v1.11/bundler_workflow.haml b/source/v1.11/bundler_workflow.haml new file mode 100644 index 0000000000..b05de90b5d --- /dev/null +++ b/source/v1.11/bundler_workflow.haml @@ -0,0 +1,198 @@ +%h2 Recommended Workflow with Version Control +.contents + .bullet#recommended_workflow + .description + %p + In general, when working with an application managed with bundler, you + should use the following workflow: + %p + After you create your Gemfile for the first time, run + :code + $ bundle install + %p + Check the resulting Gemfile.lock into version control + :code + $ git add Gemfile.lock + %p + When checking out this repository on another development machine, run + :code + $ bundle install + %p + When checking out this repository on a deployment machine, run + :code + $ bundle install --deployment + %p + After changing the Gemfile to reflect a new or update + dependency, run + :code + $ bundle install + %p + Make sure to check the updated Gemfile.lock into version + control + :code + $ git add Gemfile.lock + %p + If bundle install reports a conflict, manually update the + specific gems that you changed in the Gemfile + :code + $ bundle update rails thin + %p + If you want to update all the gems to the latest possible versions that + still match the gems listed in the Gemfile, run + :code + $ bundle update + +%h2 A Thorough Bundler Workflow + +.contents + .bullet + .description + Getting started with bundler is easy! Open a terminal window and run this command: + :code + $ gem install bundler + .notes + %li + When you first create a Rails application, it already comes with a + Gemfile. For another kind of application (such as Sinatra), run: + + :code + $ bundle init + + %li + The bundle init command creates a simple Gemfile which you + can edit. + + .bullet + .description + Specify your dependencies in the root of your application, called the Gemfile. + It looks something like this: + :code + # lang: ruby + source 'https://rubygems.org' + gem 'nokogiri' + gem 'rack', '~>1.1' + gem 'rspec', :require => 'spec' + + .notes + This Gemfile says a few things. First, it says that bundler should + look for gems declared in the Gemfile at https://rubygems.org by default. + = link_to 'Learn More: Gemfiles', './gemfile.html' + + .bullet + .description + %p + After declaring your first set of dependencies, you tell bundler to go get them: + + :code + $ bundle install # bundle is a shortcut for bundle install + + %p + Bundler will connect to rubygems.org (and any other sources that you declared), + and find a list of all of the required gems that meet the requirements you specified. + Because all of the gems in your Gemfile have dependencies of their own + (and some of those have their own dependencies), running bundle install on the + Gemfile above will install quite a few gems. + + :code + $ bundle install + Fetching gem metadata from https://rubygems.org/ + Resolving dependencies... + Using rake (0.8.7) + Using abstract (1.0.0) + Installing activesupport (3.0.0.rc) + Using builder (2.1.2) + Using i18n (0.4.1) + Installing activemodel (3.0.0.rc) + Using erubis (2.6.6) + Using rack (1.2.1) + Installing rack-mount (0.6.9) + Using rack-test (0.5.4) + Using tzinfo (0.3.22) + Installing actionpack (3.0.0.rc) + Using mime-types (1.16) + Using polyglot (0.3.1) + Using treetop (1.4.8) + Using mail (2.2.5) + Installing actionmailer (3.0.0.rc) + Using arel (0.4.0) + Installing activerecord (3.0.0.rc) + Installing activeresource (3.0.0.rc) + Using bundler (1.0.0.rc.3) + Installing nokogiri (1.4.3.1) with native extensions + Installing rack-cache (0.5.2) + Installing thor (0.14.0) + Installing railties (3.0.0.rc) + Installing rails (3.0.0.rc) + Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. + + %p + If any of the needed gems are already installed, Bundler will use them. After installing + any needed gems to your system, bundler writes a snapshot of all of the gems and + versions that it installed to Gemfile.lock. + + .notes + + %li + If bundle install reports a conflict between your Gemfile and + Gemfile.lock, run: + + :code + $ bundle update sinatra + + %li + This will update just the Sinatra gem, as well as any of its dependencies. + + %p + %li + To update all of the gems in your Gemfile to the latest possible versions, run: + + :code + $ bundle update + + %li + Whenever your Gemfile.lock changes, always check it in to version control. + It keeps a history of the exact versions of all third-party code that you used to successfully + run your application. + + %li + The git add Gemfile* command adds the Gemfile and Gemfile.lock to your repository. This ensures that + other developers on your app, as well as your deployment environment, will all use the same + third-party code that you are using now. + .buttons + = link_to 'Learn More: bundle install', './bundle_install.html' + = link_to 'Learn More: bundle update', './bundle_update.html' + .bullet + .description + Inside your app, load up the bundled environment: + :code + # lang: ruby + require 'rubygems' + require 'bundler/setup' + + # require your gems as usual + require 'nokogiri' + = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + .bullet + .description + Run an executable that comes with a gem in your bundle: + :code + $ bundle exec rspec spec/models + .notes + %p + In some cases, running executables without bundle exec + may work, if the executable happens to be installed in your system + and does not pull in any gems that conflict with your bundle. + %p + However, this is unreliable and is the source of considerable pain. + Even if it looks like it works, it may not work in the future or + on another machine. + .bullet + .description + Finally, if you want a way to get a shortcut to gems in your bundle: + :code + $ bundle install --binstubs + $ bin/rspec spec/models + .notes + The executables installed into bin are scoped to the + bundle, and will always work. + = link_to 'Learn More: Executables', './man/bundle-exec.1.html' diff --git a/source/v1.11/commands.haml b/source/v1.11/commands.haml new file mode 100644 index 0000000000..e937aae548 --- /dev/null +++ b/source/v1.11/commands.haml @@ -0,0 +1,124 @@ +%h2 Command Line Reference + +#command_reference + %table{:cellspacing => 0} + %tr + %th + command + %th + applicable options + = command_table_row do |command| + - command.name = 'binstubs' + - command.desc = 'Installs the binstubs of the listed gem' + - command.option = 'force' + - command.option = 'path' + = command_table_row do |command| + - command.name = 'check' + - command.desc = 'Checks if the dependencies listed in Gemfile are satisfied by currently installed gems' + - command.option = 'dry-run' + - command.option = 'gemfile' + - command.option = 'path' + = command_table_row do |command| + - command.name = 'clean' + - command.desc = 'Cleans up unused gems in your bundler directory' + - command.option = 'dry-run' + - command.option = 'force' + = command_table_row do |command| + - command.name = 'config' + - command.desc = 'Retrieve or set a configuration value' + - command.option = 'local' + - command.option = 'global' + - command.option = 'delete' + = command_table_row do |command| + - command.name = 'console' + - command.desc = 'Opens an IRB session with the bundle pre-loaded' + = command_table_row do |command| + - command.name = 'exec' + - command.desc = 'Run the command in context of the bundle' + - command.option = 'keep-file-descriptors' + = command_table_row do |command| + - command.name = 'gem' + - command.desc = 'Creates a skeleton for creating a rubygem' + - command.option = 'bin or -b' + - command.option = 'edit' + - command.option = 'ext' + - command.option = 'test' + = command_table_row do |command| + - command.name = 'help' + - command.desc = 'Displays detailed help for each subcommand' + = command_table_row do |command| + - command.name = 'init' + - command.desc = 'Generates a Gemfile into the current working directory' + - command.option = 'gemspec' + = command_table_row do |command| + - command.name = 'inject' + - command.desc = 'Add the named gem(s), with version requirements, to the resolved Gemfile' + = command_table_row do |command| + - command.name = 'install' + - command.desc = 'Install the current environment to the system' + - command.option = 'binstubs' + - command.option = 'clean' + - command.option = 'deployment' + - command.option = 'frozen' + - command.option = 'full-index' + - command.option = 'gemfile' + - command.option = 'jobs' + - command.option = 'local' + - command.option = 'no-cache' + - command.option = 'no-prune' + - command.option = 'path' + - command.option = 'quiet' + - command.option = 'retry' + - command.option = 'shebang' + - command.option = 'standalone' + - command.option = 'system' + - command.option = 'trust-policy' + - command.option = 'without' + = command_table_row do |command| + - command.name = 'open' + - command.desc = 'Opens the source directory of the given bundled gem' + = command_table_row do |command| + - command.name = 'outdated' + - command.desc = 'List installed gems with newer versions available' + - command.option = 'local' + - command.option = 'pre' + - command.option = 'source' + - command.option = 'strict' + = command_table_row do |command| + - command.name = 'package' + - command.desc = 'Locks and then caches all of the gems into vendor/cache' + - command.option = 'all' + - command.option = 'all-platforms' + - command.option = 'gemfile' + - command.option = 'no-install' + - command.option = 'no-prune' + - command.option = 'path' + - command.option = 'quiet' + = command_table_row do |command| + - command.name = 'platform' + - command.desc = 'Displays platform compatibility information' + - command.option = 'ruby' + = command_table_row do |command| + - command.name = 'show' + - command.desc = 'Shows all gems that are part of the bundle, or the path to a given gem' + - command.option = 'paths' + = command_table_row do |command| + - command.name = 'update' + - command.desc = 'Update the current environment' + - command.option = 'full-index' + - command.option = 'group' + - command.option = 'jobs' + - command.option = 'local' + - command.option = 'quiet' + - command.option = 'source' + = command_table_row do |command| + - command.name = 'version' + - command.desc = 'Prints version information' + = command_table_row do |command| + - command.name = 'viz' + - command.desc = 'Generates a visual dependency graph' + - command.option = 'file or -f' + - command.option = 'format or -F' + - command.option = 'requirements or -r' + - command.option = 'version or -v' + - command.option = 'without' diff --git a/source/v1.11/deploying.haml b/source/v1.11/deploying.haml new file mode 100644 index 0000000000..fc6502db1e --- /dev/null +++ b/source/v1.11/deploying.haml @@ -0,0 +1,155 @@ +%h2 Deploying bundled applications +.contents + .bullet + .description + 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. + :code + $ echo ".bundle" >> .gitignore + $ git add Gemfile Gemfile.lock .gitignore + $ git commit -m "Add Bundler support" + .notes + Once you have done that, there are two ways to deploy using Bundler: + manually or automatically. + + .bullet + .description + %h3 Manual deployment + In your deploy script, after updating to the latest + code, install your bundle to the vendor/bundle + directory, ensuring all your dependencies are met. + :code + $ bundle install --deployment + .notes + %p + Start your application servers as usual, and your + application will use your bundled environment + with the exact same gems you use in development. + + %p + If you have run bundle package, the cached + gems will be used automatically. + + = link_to 'Learn More: Packing', './bundle_package.html' + + .bullet + %h3 Automatic deployment with Capistrano + .description + To pull in the Bundler Cap task, just add this to your + deploy.rb file: + :code + # lang: ruby + require 'bundler/capistrano' + .notes + That's it! Running cap deploy will now automatically run + bundle install on the remote server with deployment-friendly + options. A list of options that can be changed is available in the help + for the cap task. To see it, run cap -e bundle:install. + + .bullet + .description + %h3 Automatic deployment with Vlad + There is a default Vlad task available. To make it available, add this line + to the Vlad deploy.rb. + :code + # lang: ruby + require 'bundler/vlad' + .notes + Once you have done that, the vlad:bundle:install task will be + available for use. Make sure it is run as part of your deploy. For example: + :code + # lang: ruby + task "vlad:deploy" => %w[ + vlad:update vlad:bundle:install vlad:start_app vlad:cleanup + ] + + .bullet + .description + %h3 After deploying + Make sure to use bundle exec to run any executables + from gems in the bundle + :code + $ bundle exec rake db:setup + .notes + Alternatively, you can use the --binstubs option on the + install command to generate executable binaries that can be used instead of + bundle exec. + = link_to 'Learn More: Executables', './man/bundle-exec.1.html' + + .bullet + .description + %h3 Heroku + When you deploy to Heroku, Bundler will be run automatically as long as a Gemfile is present. If you check in your Gemfile.lock, Heroku will run `bundle install --deployment`. If you want to exclude certain groups using the --without option, you need to use `heroku config`. + :code + $ heroku config:add BUNDLE_WITHOUT="test development" --app app_name + = link_to 'Heroku Bundler Documentation', 'http://docs.heroku.com/bundler' + + %h2#deploying-your-application + Deploying Your Application + + .bullet + .description + When you run bundle install, bundler will (by default), install your gems + to your system repository of gems. This means that they will show up in gem + list. Additionally, if you are developing a number of applications, you will not + need to download and install gems in common for each application. This is nice for + development, but somewhat problematic for deployment. + + %p.description + In a deployment scenario, the Unix user you deploy with may not have access to install + gems to a system location. Even if the user does (or you use sudo), the + user that boots the application may not have access to them. For instance, Passenger + runs its Ruby subprocesses with the user nobody, a somewhat restricted + user. The tradeoffs in a deployment environment lean more heavily in favor of isolation + (even at the cost of a somewhat slower deploy-time bundle install when some + third-party dependencies have changed). + + %p.description + As a result, bundler comes with a --deployment flag that encapsulates the + best practices for using bundler in a deployment environment. These practices are based + on significant feedback we have received during the development of bundler, as well as a + number of bug reports that mostly reflected a misunderstanding of how to best configure + bundler for deployment. The --deployment flags adds the following defaults: + + .description + %ul + %li + Instead of installing gems to the system location, bundler will install gems to + vendor/bundle inside your application. Bundler will transparently remember + this location when you invoke it inside your application (with + Bundler.setup and Bundler.require). + %li + Bundler will not use gems already installed to your system, even if they exist. + %li + If you have run bundle pack, checked in the vendor/cache + directory, and do not have any git gems, Bundler will not contact the internet while + installing your bundle. + %li + Bundler will require a Gemfile.lock snapshot, and fail if you did not + provide one. + %li + Bundler will not transparently update your Gemfile.lock if it is out of + date with your Gemfile + + %p.description + If you use Capistrano, you should symlink vendor/bundle to + shared/vendor_bundle so that bundler will share your installed gems between + deployments (making things zippy if you didn't make any changes), but still give you the + benefits of isolation from other applications. + + %p.description + By defaulting the bundle directory to vendor/bundle, and installing your + bundle as part of your deployment process, you can be sure that the same Unix user that + checked out your application also installed the third-party code your application needs. + This means that if Passenger (or Unicorn) can see your application, it can also see its + dependencies. + + %p.description + The --deployment flag requires an up-to-date Gemfile.lock to + ensure that the testing you have done (in development and staging) actually reflects the + code you put into production. You can run bundle check before deploying + your application to make sure that your Gemfile.lock is up-to-date. Note + that it will always be up-to-date if you have run bundle install, + successfully booted your application (or run your tests) since the last time you changed + your Gemfile. diff --git a/source/v1.11/faq.haml b/source/v1.11/faq.haml new file mode 100644 index 0000000000..9ba637e411 --- /dev/null +++ b/source/v1.11/faq.haml @@ -0,0 +1,167 @@ +%h2#faq + FAQ - Frequently Asked Questions +.contents + .bullet + .description + %h3 + Why Can't I Just Specify Only = Dependencies? + %p + Q: I understand the value of locking my gems down + to specific versions, but why can't I just specify = versions + for all my dependencies in the Gemfile and forget about + the Gemfile.lock? + + %p + A: Many of your gems will have their own + dependencies, and they are unlikely to specify = dependencies. + Moreover, it is probably unwise for gems to lock down all of *their* + dependencies so strictly. The Gemfile.lock allows you to + specify the versions of the dependencies that your application needs in + the Gemfile, while remembering all of the exact versions of + third-party code that your application used when it last worked correctly. + + %p + By specifying looser dependencies in your Gemfile + (such as nokogiri ~> 1.4.2), you gain the ability to run + bundle update nokogiri, and let bundler handle updating **only** + nokogiri and its dependencies to the latest version that still + satisfied the ~> 1.4.2 version requirement. This also allows you + to say "I want to use the current version of nokogiri" (gem 'nokogiri' + in your Gemfile) without having to look up the exact version number, + while still getting the benefits of ensuring that your application always runs with + exactly the same versions of all third-party code. + + %h3 + Why Can't I Just Submodule Everything? + + %p + Q: I don't understand why I need bundler to manage + my gems in this manner. Why can't I just get the gems I need and stick them + in submodules, then put each of the submodules on the load path? + + %p + A: Unfortunately, that solution requires that you + manually resolve all of the dependencies in your application, including dependencies + of dependencies. And even once you do that successfully, you would need to redo that + work if you wanted to update a particular gem. For instance, if you wanted to update + the rails gem, you would need to find all of the gems that depended on + dependencies of Rails (rack, erubis, i18n, + tzinfo, etc.), and find new versions that satisfy the new versions of + Rails' requirements. + + %p + Frankly, this is the sort of problem that computers are good at, and which you, + a developer, should not need to spend time doing. + + %p + More concerningly, if you made a mistake in the manual dependency resolution + process, you would not get any feedback about conflicts between different dependencies, + resulting in subtle runtime errors. For instance, if you accidentally stuck the wrong + version of rack in a submodule, it would likely break at runtime, when + Rails or another dependency tried to rely on a method that was not present. + + %p + %strong + Bottom line: + + even though it might seem simpler at first glance, it is decidedly significantly + more complex. + + %h3 + Why Is Bundler Downloading Gems From --without Groups? + + %p + Q: I ran bundle install --without production and + bundler is still downloading the gems in the :production group. Why? + + %p + A: Bundler's Gemfile.lock has to contain exact + versions of all dependencies in your Gemfile, regardless of any options + you pass in. If it did not, deploying your application to production might change all + your dependencies, eliminating the benefit of Bundler. You could no longer be sure that + your application uses the same gems in production that you used to develop and test with. + Additionally, adding a dependency in production might result in an application that is + impossible to deploy. + + %p + For instance, imagine you have a production-only gem (let's call it + rack-debugging) that depends on rack =1.1. If we did not evaluate + the production group when you ran bundle install --without production, you + would deploy your application, only to receive an error that rack-debugging + conflicted with rails (which depends on actionpack, which depends + on rack ~> 1.2.1). + + %p + Another example: imagine a simple Rack application that has gem 'rack' + in the Gemfile. Again, imagine that you put rack-debugging in the + :production group. If we did not evaluate the :production group when + you installed via bundle install --without production, your app would use + rack 1.2.1 in development, and you would learn, at deployment time, that + rack-debugging conflicts with the version of Rack that you tested with. + + %p + In contrast, by evaluating the gems in **all** groups when you call bundle install, + regardless of the groups you actually want to use in that environment, we will discover the + rack-debugger requirement, and install rack 1.1, which is also compatible + with the gem 'rack' requirement in your Gemfile. + + %p + %strong + In short, + by always evaluating all of the dependencies in your Gemfile, regardless of the dependencies + you intend to use in a particular environment, you avoid nasty surprises when switching to a different + set of groups in a different environment. And because we just download (but do not install) the gems, + you won't have to worry about the possibility of a difficult **installation** process for a gem that + you only use in production (or in development). + + %h3 + I Have a C Extension That Requires Special Flags to Install + + %p + Q: I have a C extension gem, such as mysql, which requires + special flags in order to compile and install. How can I pass these flags into the installation + process for those gems? + + %p + A: First of all, this problem does not exist for the mysql2 + gem, which is a drop-in replacement for the mysql gem. In general, modern C extensions + properly discover the needed headers. + + %p + If you really need to pass flags to a C extension, you can use the bundle config + command: + + :code + $ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config + + %p + Bundler will store this configuration in ~/.bundle/config, and bundler will use + the configuration for any bundle install performed by the same user. As a result, once + you specify the necessary build flags for a gem, you can successfully install that gem as many times + as necessary. + + %h3 + I Do Not Have an Internet Connection and Bundler Keeps Trying to Connect to the Gem Server + %p + Q: I do not have an internet connection but I have installed the gem before. + How do I get bundler to use my local gem cache and not connect to the gem server? + + %p + A: Use the --local flag with bundle install. The --local flag tells bundler + to use the local gem cache instead of reaching out to the remote gem server. + + :code + $ bundle install --local + + %h3 + Bundling From RubyGems is Really Slow + + %p + Q: When I bundle from rubygems it is really slow. Is there anything I can do to make it faster? + + %p + A: Add the --full-index flag when bundling from the rubygems server. This downloads + the index all at once instead of making numerous small requests to the api. + + :code + $ bundle install --full-index diff --git a/source/v1.11/gemfile.haml b/source/v1.11/gemfile.haml new file mode 100644 index 0000000000..9f318f99a6 --- /dev/null +++ b/source/v1.11/gemfile.haml @@ -0,0 +1,155 @@ +%h2 In Depth + +.contents + .bullet + .description + Read the manual for an in-depth discussion of all of the options available in the + Gemfile and how to use them. + = link_to 'Gemfile manual', './man/gemfile.5.html' + +%h2 Gemfiles + +.contents + .bullet + .description + Gemfiles require at least one gem source, in the form of the URL for a RubyGems server. Generate a Gemfile with the default rubygems.org source by running bundle init. If you can, use https so your connection to the rubygems.org server will be verified with SSL. + :code + # lang: ruby + source 'https://rubygems.org' + .notes + It is possible, but not recommended as of Bundler 1.7, to add multiple global source lines. These are searched from last to first. + + .bullet + .description + Some gem sources require a username and password. Use + bundle config to set the username and password for any + sources that need it. The command must be run once on each computer that + will install the Gemfile, but this keeps the credentials from being stored + in plain text in version control. + :code + $ bundle config https://gems.example.com/ user:password + .description + For some sources, like a company Gemfury account, it may be easier to + simply include the credentials in the Gemfile as part of the source URL. + :code + # lang: ruby + source "https://user:password@gems.example.com" + .description + Credentials in the source URL will take precedence over credentials set + using config. + + .bullet + .description + Declare the gems that you need, including version numbers. Specify versions using the same + syntax that RubyGems supports for dependencies. + :code + # lang: ruby + gem 'nokogiri' + gem 'rails', '3.0.0.beta3' + gem 'rack', '>=1.0' + gem 'thin', '~>1.1' + .notes + Most of the version specifiers, like >= 1.0, are self-explanatory. + The specifier ~> has a special meaning, best shown by example. + ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. + ~> 2.1 is identical to >= 2.1 and < 3.0. + ~> 2.2.beta will match prerelease versions like 2.2.beta.12. + = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' + + .bullet + .description + If a gem's main file is different than the gem name, specify how to require it. + :code + # lang: ruby + gem 'rspec', :require => 'spec' + gem 'sqlite3' + .description + Specify :require => false to prevent bundler from requiring the gem, but still install it and maintain dependencies. + :code + # lang: ruby + gem 'rspec', :require => false + gem 'sqlite3' + .notes + In order to require gems in your Gemfile, you will need to call + Bundler.require in your application. + = link_to 'Learn More: Bundler.require', './groups.html' + + .bullet + .description + If some of your gems need to be fetched from a private gem server, this default source can be overridden for those gems. + + For a gem server that contains a single gem, it is easiest to use the :source option on that gem. + :code + # lang: ruby + gem 'my_gem', '1.0', :source => 'https://gems.example.com' + .description + If several gems come from the same server, you can use a source block to group them together. + :code + # lang: ruby + source 'https://gems.example.com' do + gem 'my_gem', '1.0' + gem 'another_gem', '1.2.1' + end + .description + Credentials for gem servers can be specified either in the URL or using + bundle config, as described above. + + .bullet + .description + Git repositories are also valid gem sources, as long as the repo contains one or + more valid gems. Specify what to check out with :tag, + :branch, or :ref. The default is the master branch. + :code + # lang: ruby + gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git', :branch => '1.4' + .notes + If the git repository does not contain a .gemspec file, bundler + will create a simple one, without any dependencies, executables or C extensions. + This may work for simple gems, but not work for others. If there is no .gemspec, + you probably shouldn't use the gem from git. + = link_to 'Learn more: Git', './git.html' + + .bullet + .description + If you would like to use a unpacked gem directly from the filesystem, simply set the :path option to the path containing the gem's files. + :code + # lang: ruby + gem 'extracted_library', :path => './vendor/extracted_library' + + .bullet + .description + If you would like to use multiple local gems directly from the filesystem, you can set a global `path` option to the path containing the gem's files. This will automatically load gemspec files from subdirectories. + :code + # lang: ruby + path 'components' do + gem 'admin_ui' + gem 'public_ui' + end + + .bullet + .description + Dependencies can be placed into groups. Groups can be ignored at install-time (using --without) or required all at once (using Bundler.require). + :code + # lang: ruby + gem 'wirble', :group => :development + gem 'debugger', :group => [:development, :test] + + group :test do + gem 'rspec' + end + = link_to 'Learn more: Groups', './groups.html' + + .bullet + .description + You can specify the required version of Ruby in the Gemfile with ruby. If the Gemfile is loaded on a different Ruby version, Bundler will raise an exception with an explanation. + :code + # lang: ruby + ruby '1.9.3' + + .bullet + .description + What this means is that this app has a dependency to a Ruby VM that is ABI compatible with 1.9.3. If the version check does not match, Bundler will raise an exception. This will ensure the running code matches. You can be more specific with the :engine and :engine_version options. + :code + # lang: ruby + ruby '1.9.3', :engine => 'jruby', :engine_version => '1.6.7' + = link_to 'Learn More: Ruby Directive', './gemfile_ruby.html' diff --git a/source/v1.11/gemfile_ruby.haml b/source/v1.11/gemfile_ruby.haml new file mode 100644 index 0000000000..15fc691d2c --- /dev/null +++ b/source/v1.11/gemfile_ruby.haml @@ -0,0 +1,44 @@ +%h2 Specifying a Ruby Version + +.contents + .bullet + .description + Like gems, developers can setup a dependency on Ruby. This makes your app fail faster in case you depend on specific features in a Ruby VM. This way, the Ruby VM on your deployment server will match your local one. You can do this by using the ruby directive in the Gemfile: + :code + # lang: ruby + ruby 'RUBY_VERSION', :engine => 'ENGINE', :engine_version => 'ENGINE_VERSION', + :patchlevel => 'RUBY_PATCHLEVEL' + + .bullet + .description + If you wanted to use JRuby 1.6.7 using Ruby 1.9.3, you would simply do the following: + :code + # lang: ruby + ruby '1.9.3', :engine => 'jruby', :engine_version => '1.6.7' + + .bullet#patchlevel + .description + It's also possible to restrict the patchlevel of the Ruby used by doing the following: + :code + # lang: ruby + ruby '1.9.3', :patchlevel => '448' + + .bullet + .description + Bundler will make checks against the current running Ruby VM to make sure it matches what is specified in the Gemfile. If things don't match, Bundler will raise an Exception explaining what doesn't match. + :code + Your Ruby version is 1.8.7, but your Gemfile specified 1.9.3 + + .bullet + .description + Both :engine and :engine_version are optional. When these options are omitted, this means the app is compatible with a particular Ruby ABI but the engine is irrelevant. When :engine is used, :engine_version must also be specified. + .bullet + .description + Using the platform command with the --ruby flag, you can see what ruby directive is specified in the Gemfile. + :code + ruby 1.9.3 (jruby 1.6.7) + = link_to 'Learn More: bundle platform', './bundle_platform.html' + + .bullet + .description + In the ruby directive, :patchlevel is optional, as patchlevel releases are usually compatible and include important security fixes. The patchlevel option checks the RUBY_PATCHLEVEL constant, and if not specified then bundler will simply ignore it. diff --git a/source/v1.11/git.haml b/source/v1.11/git.haml new file mode 100644 index 0000000000..5a9a0216b0 --- /dev/null +++ b/source/v1.11/git.haml @@ -0,0 +1,192 @@ +%h2 Gems from git repositories + +.contents + .bullet + .description + Bundler adds the ability to use gems directly from git repositories. Setting + them up is as easy as adding a gem to your Gemfile. Using the very latest + version of a gem (or even a fork) is just as easy as using an official + release. + .description + Because RubyGems lacks the ability to handle gems from git, any gems + installed from a git repository will not show up in gem list. + They will, however, be available after running Bundler.setup. + + .bullet + .description + Specify that a gem should come from a git + repository with a .gemspec at its root + :code + # lang: ruby + gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git' + + .bullet + .description + If there is no .gemspec at the root of + a git repository, you must specify a version + that bundler should use when resolving + dependencies + :code + # lang: ruby + gem 'deep_merge', '1.0', :git => 'https://github.com/peritor/deep_merge.git' + + .bullet + .description + Specify that a git repository containing + multiple .gemspec files should be treated + as a gem source + :code + # lang: ruby + git 'https://github.com/rails/rails.git' do + gem 'railties' + gem 'action_pack' + gem 'active_model' + end + + .bullet + .description + Specify that a git repository should use + a particular ref, branch, or tag + :code + # lang: ruby + :git => 'https://github.com/rails/rails.git', :ref => '4aded' + :git => 'https://github.com/rails/rails.git', :branch => '2-3-stable' + :git => 'https://github.com/rails/rails.git', :tag => 'v2.3.5' + + .bullet + .description + Specifying a ref, branch, or tag for a + git repository specified inline works + exactly the same way + :code + # lang: ruby + gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git', :ref => '0eec4' + + .bullet + .description + Bundler can use HTTP(S), SSH, or git + :code + # lang: ruby + gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git' + gem 'nokogiri', :git => 'git@github.com:tenderlove/nokogiri.git' + gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git' + + .bullet + .description + Specify that the submodules from a git repository + also should be expanded by bundler + :code + # lang: ruby + gem 'rugged', :git => 'git://github.com/libgit2/rugged.git', :submodules => true + + .bullet + .description + If you are getting your gems from a public GitHub repository, + you can use the shorthand + :code + # lang: ruby + gem 'nokogiri', :github => 'tenderlove/nokogiri' + .description + If the repository name is the same as the GitHub account hosting it, + you can omit it + :code + # lang: ruby + gem 'rails', :github => 'rails' + .description + NB: This shorthand can only be used for public repos in Bundler version 1.x. Use HTTPS for read and write: + :code + # lang: ruby + gem 'rails', :git => 'https://github.com/rails/rails' + .description + All of the usual :git options apply, like :branch and :ref. + :code + # lang: ruby + gem 'rails', :github => 'rails', :ref => 'a9752dcfd15bcddfe7b6f7126f3a6e0ba5927c56' + .description + There are analogous shortcuts for Bitbucket (:bitbucket) and GitHub Gists (:gist). + :code + # lang: ruby + gem 'capistrano-sidekiq', :github => 'seuros/capistrano-sidekiq' + gem 'keystone', :bitbucket => 'musicone/keystone' + + +%h2 Custom git sources +.contents + .bullet + .description + The :github shortcut used above is one of Bundler's built in git sources. Bundler comes + with shortcuts for :github, :gist, and :bitbucket, but you can + also add your own. + + .description + If you're using Github Enterprise, Stash, or just have a custom git setup, create your own shortcuts + by calling git_source before you use your custom option. Here's an example for Stash: + + :code + # lang: ruby + git_source(:stash){ |repo_name| "https://stash.corp.acme.pl/\#{repo_name}.git" } + gem 'rails', :stash => 'forks/rails' + +%h2 Security +.contents + .bullet + .description + http:// and git:// URLs are insecure. A + man-in-the-middle attacker could tamper with the code as you check it out, + and potentially supply you with malicious code instead of the code you meant to + check out. Because the :github shortcut uses a git:// + URL in Bundler 1.x versions, we recommend using using HTTPS URLs or overriding + the :github shortcut with your own HTTPS git source. + +%h2#local Local Git Repos +.contents + .bullet + .description + Bundler also allows you to work against a git repository locally + instead of using the remote version. This can be achieved by setting + up a local override: + :code + bundle config local.GEM_NAME /path/to/local/git/repository + + .bullet + .description + For example, in order to use a local Rack repository, a developer could call: + :code + bundle config local.rack ~/Work/git/rack + .description + and setup the git repo pointing to a branch: + :code + # lang: ruby + gem 'rack', :github => 'rack/rack', :branch => 'master' + + .bullet + .description + %p + Now instead of checking out the remote git repository, the local + override will be used. Similar to a path source, every time the local + git repository change, changes will be automatically picked up by + Bundler. This means a commit in the local git repo will update the + revision in the Gemfile.lock to the local git repo revision. This + requires the same attention as git submodules. Before pushing to + the remote, you need to ensure the local override was pushed, otherwise + you may point to a commit that only exists in your local machine. + + %p + Bundler does many checks to ensure a developer won't work with + invalid references. Particularly, we force a developer to specify + a branch in the Gemfile in order to use this feature. If the branch + specified in the Gemfile and the current branch in the local git + repository do not match, Bundler will abort. This ensures that + a developer is always working against the correct branches, and prevents + accidental locking to a different branch. + + %p + Finally, Bundler also ensures that the current revision in the + Gemfile.lock exists in the local git repository. By doing this, Bundler + forces you to fetch the latest changes in the remotes. + + .bullet + .description + %p If you do not want bundler to make these branch checks, you can override it by setting this option: + :code + bundle config disable_local_branch_check true diff --git a/source/v1.11/groups.haml b/source/v1.11/groups.haml new file mode 100644 index 0000000000..d176cff654 --- /dev/null +++ b/source/v1.11/groups.haml @@ -0,0 +1,137 @@ +%h2 Using Groups + +.contents + .bullet + .description + Grouping your dependencies allows you + to perform operations on the entire + group. + :code + # lang: ruby + # These gems are in the :default group + gem 'nokogiri' + gem 'sinatra' + + gem 'wirble', :group => :development + + group :test do + gem 'faker' + gem 'rspec' + end + + group :test, :development do + gem 'capybara' + gem 'rspec-rails' + end + + gem 'cucumber', :group => [:cucumber, :test] + + .bullet + .description + Install all gems, except those in the + listed groups. Gems in at least one + non-excluded group will still be installed. + :code + $ bundle install --without test development + + .bullet + .description + Require the gems in particular groups, + noting that gems outside of a named group + are in the :default group + :code + # lang: ruby + Bundler.require(:default, :development) + + .bullet + .description + Require the default gems, plus the gems + in a group named the same as the current + Rails environment + :code + # lang: ruby + Bundler.require(:default, Rails.env) + + .bullet + .description + Restrict the groups of gems that you + want to add to the load path. Only gems + in these groups will be require'able + :code + # lang: ruby + require 'rubygems' + require 'bundler' + Bundler.setup(:default, :ci) + require 'nokogiri' + = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + + %h2#grouping-your-dependencies + Grouping Your Dependencies + .bullet + .description + You'll sometimes have groups of gems that only make sense in particular environments. + For instance, you might develop your app (at an early stage) using SQLite, but deploy it + using mysql2 or pg. In this example, you might not have MySQL + or Postgres installed on your development machine, and want bundler to skip it. + + To do this, you can group your dependencies: + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'rails', '3.2.2' + gem 'rack-cache', :require => 'rack/cache' + gem 'nokogiri', '~> 1.4.2' + + group :development do + gem 'sqlite3' + end + + group :production do + gem 'pg' + end + + .bullet + .description + Now, in development, you can instruct bundler to skip the production group: + + :code + $ bundle install --without production + + .bullet + .description + Bundler will remember that you installed the gems using --without + production. For curious readers, bundler stores the flag in + APP_ROOT/.bundle/config. You can see all of the settings that bundler saved + there by running bundle config, which will also print out global settings + (stored in ~/.bundle/config), and settings set via environment variables. + For more information on configuring bundler, please see: + #{link_to 'bundle config', './bundle_config.html'} + + .bullet + %p.description + If you run bundle install later, without any flags, bundler will remember + that you last called bundle install --without production, and use that flag + again. When you require 'bundler/setup', bundler will ignore gems in these + groups. + + %p.description + You can also specify which groups to automatically require through the parameters to + Bundler.require. The :default group includes all gems not + listed under any group. If you call Bundler.require(:default, :development), + bundler will require all the gems in the :default group, as + well as the gems in the :development group. + + %p.description + By default, a Rails generated app calls Bundler.require(:default, + Rails.env) in your application.rb, which links the groups in your + Gemfile to the Rails environment. If you use other groups (not linked to a + Rails environment), you can add them to the call to Bundler.require, if you + want them to be automatically required. + + %p.description + Remember that you can always leave groups of gems out of Bundler.require, + and then require them manually using Ruby's require at the appropriate + place in your app. You might do this because requiring a certain gem takes some time, + and you don't need it every time you boot your application. diff --git a/source/v1.11/index.haml b/source/v1.11/index.haml new file mode 100644 index 0000000000..170e2f1d04 --- /dev/null +++ b/source/v1.11/index.haml @@ -0,0 +1,140 @@ +%h2 What is Bundler? + +%p#intro + Bundler provides a consistent environment for Ruby projects by tracking + and installing the exact gems and versions that are needed. + %br + %br + Bundler is an exit from dependency hell, and ensures that the gems + you need are present in development, staging, and production. + Starting work on a project is as simple as bundle install. + +.buttons + = link_to 'What\'s new in Bundler', './whats_new.html' + = link_to 'Why Bundler exists', './rationale.html' + +%h2#getting-started + Getting Started + +.contents + .bullet + .description + %p + Getting started with bundler is easy! Open a terminal window and run this command: + :code + $ gem install bundler + + .bullet + .description + %p + Specify your dependencies in a Gemfile in your project's root: + :code + # lang: ruby + source 'https://rubygems.org' + gem 'nokogiri' + gem 'rack', '~>1.1' + gem 'rspec', :require => 'spec' + = link_to 'Learn More: Gemfiles', './gemfile.html' + + .bullet + .description + %p + Install all of the required gems from your specified sources: + :code + $ bundle install + $ git add Gemfile Gemfile.lock + = link_to 'Learn More: bundle install', './bundle_install.html' + .notes + %p + The second command adds the Gemfile and Gemfile.lock to your repository. This ensures + that other developers on your app, as well as your deployment environment, will all use + the same third-party code that you are using now. + + .bullet + .description + %p + Inside your app, load up the bundled environment: + :code + # lang: ruby + require 'rubygems' + require 'bundler/setup' + + # require your gems as usual + require 'nokogiri' + = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + .bullet + .description + %p + Run an executable that comes with a gem in your bundle: + :code + $ bundle exec rspec spec/models + .notes + %p + In some cases, running executables without bundle exec + may work, if the executable happens to be installed in your system + and does not pull in any gems that conflict with your bundle. + %p + However, this is unreliable and is the source of considerable pain. + Even if it looks like it works, it may not work in the future or + on another machine. + + .description + %p + Finally, if you want a way to get a shortcut to gems in your bundle: + :code + $ bundle install --binstubs + $ bin/rspec spec/models + .notes + %p + The executables installed into bin are scoped to the + bundle, and will always work. + = link_to 'Learn More: Executables', './man/bundle-exec.1.html' + +%h2#create-gem Create a rubygem with Bundler + +%p + Bundler is also an easy way to create new gems. Just like you might create a standard Rails project using rails new, you can create a standard gem project with bundle gem. + +.bullet + .description + %p + Create a new gem with a README, .gemspec, Rakefile, directory structure, and all the basic boilerplate you need to describe, test, and publish a gem: + :code + $ bundle gem my_gem + Creating gem 'my_gem'... + create my_gem/Gemfile + create my_gem/.gitignore + create my_gem/lib/my_gem.rb + create my_gem/lib/my_gem/version.rb + create my_gem/my_gem.gemspec + create my_gem/Rakefile + create my_gem/README.md + create my_gem/bin/console + create my_gem/bin/setup + create my_gem/CODE_OF_CONDUCT.md + create my_gem/LICENSE.txt + create my_gem/.travis.yml + create my_gem/test/test_helper.rb + create my_gem/test/my_gem_test.rb + Initializing git repo in ./my_gem + + = link_to 'Learn More: bundle gem', './bundle_gem.html' + +%h2#use-bundler Use Bundler with +.buttons + = link_to 'Rails 3', './rails3.html' + = link_to 'Rails 2.3', './rails23.html' + = link_to 'Sinatra', './sinatra.html' + = link_to 'RubyGems', './rubygems.html' + = link_to 'RubyMotion', './rubymotion.html' + +%h2#get-involved Get involved +%p + Bundler has a lot of contributors and users, and they all talk to each other quite a bit. If you have questions, try #{link_to 'the IRC channel', 'http://webchat.freenode.net/?channels=bundler'} or #{link_to 'mailing list', 'http://groups.google.com/group/ruby-bundler'}. If you're interested in contributing to the project (no programming skills needed), read #{link_to 'the contributing guide', 'https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md'}. While participating in the Bundler project, please keep the #{link_to 'code of conduct', '/conduct.html'} in mind, and be inclusive and friendly towards everyone. If you have sponsorship or security questions, please contact the core team directly. + +.buttons + = link_to 'Code of Conduct', '/conduct.html' + = link_to '#bundler on IRC', 'http://webchat.freenode.net/?channels=bundler' + = link_to 'Mailing list', 'http://groups.google.com/group/ruby-bundler' + = link_to 'Contributing', 'https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md' + = link_to 'Email core team', 'mailto:team@bundler.io' diff --git a/source/v1.11/rails23.haml b/source/v1.11/rails23.haml new file mode 100644 index 0000000000..280641fa08 --- /dev/null +++ b/source/v1.11/rails23.haml @@ -0,0 +1,104 @@ +#intro + Rails 2.3 comes with its own gem handling. We're going to + override that and replace it with support for Bundler. + .notes + NB: This may work with Rails versions lower than 2.3. + The Bundler team has not tested those versions, and will not provide + support for anyone on Rails older than 2.3, but feel free to try it. :) + + +%h2 Using Bundler with Rails 2.3 + +.contents + + .bullet + .description + If you don't have a Rails 2.3 app yet, generate one + :code + $ rails myapp + $ cd myapp + + .bullet + .description + Insert the following code at the bottom of config/boot.rb, + right above the line `Rails.boot!` + :code + # lang: ruby + class Rails::Boot + def run + load_initializer + + Rails::Initializer.class_eval do + def load_gems + @bundler_loaded ||= Bundler.require :default, Rails.env + end + end + + Rails::Initializer.run(:set_load_path) + end + end + + .bullet + .description + Create a new file, config/preinitializer.rb, + and insert the following. That is config NOT + config/initializers. + :code + # lang: ruby + begin + require 'rubygems' + require 'bundler' + rescue LoadError + raise "Could not load the bundler gem. Install it with `gem install bundler`." + end + + if Gem::Version.new(Bundler::VERSION) <= Gem::Version.new("0.9.24") + raise RuntimeError, "Your bundler version is too old for Rails 2.3.\n" + + "Run `gem install bundler` to upgrade." + end + + begin + # Set up load paths for all bundled gems + ENV["BUNDLE_GEMFILE"] = File.expand_path("../../Gemfile", __FILE__) + Bundler.setup + rescue Bundler::GemNotFound + raise RuntimeError, "Bundler couldn't find some gems.\n" + + "Did you run `bundle install`?" + end + + .bullet + .description + Get all config.gem declarations from your application, and place + them into the Gemfile. If you have declarations in development.rb, + for instance, place them in a named group. Make sure to include + Rails itself and a default gem source. + :code + # lang: ruby + source 'https://rubygems.org' + gem 'rails', '~> 2.3.5' + gem 'sqlite3-ruby', :require => 'sqlite3' + + # bundler requires these gems in all environments + # gem 'nokogiri', '1.4.2' + # gem 'geokit' + + group :development do + # bundler requires these gems in development + # gem 'rails-footnotes' + end + + group :test do + # bundler requires these gems while running tests + # gem 'rspec' + # gem 'faker' + end + = link_to 'Learn More: Groups', './groups.html' + + .bullet + .description + Once you have everything set up, you can use script/console, + script/server, and other Rake tasks as usual. From this point + on, you can follow the instructions in the Rails 3 guide + :code + $ bundle exec rake db:migrate + = link_to 'Learn More: Rails 3', './rails3.html#shared_with_23' diff --git a/source/v1.11/rails3.haml b/source/v1.11/rails3.haml new file mode 100644 index 0000000000..e68b6599b6 --- /dev/null +++ b/source/v1.11/rails3.haml @@ -0,0 +1,76 @@ +#intro + Rails 3 comes with baked in support with bundler. + +%h2 Using Bundler with Rails 3 + +.contents + .bullet + .description + Install Rails as you normally would. Use sudo + if you would normally use sudo to install gems. + .how + :code + $ gem install rails + .notes + We recommend using rvm for dependable Ruby + installations, especially if you are switching + between different versions of Ruby + + .bullet + .description + Generate a Rails app as usual + :code + $ rails new myapp + $ cd myapp + + .bullet + .description + Run the server. Bundler is transparently managing + your dependencies! + :code + $ rails server + + .bullet + .description + Add new dependencies to your Gemfile as you + need them. + :code + # lang: ruby + gem 'nokogiri' + gem 'geokit' + + .bullet + .description + If you want a dependency to be loaded only in + a certain Rails environment, place it in a group + named after that Rails environment + :code + # lang: ruby + group :test do + gem 'rspec' + gem 'faker' + end + + .bullet#shared_with_23 + .description + You can place a dependency in multiple groups + at once as well + :code + # lang: ruby + group :development, :test do + gem 'wirble' + gem 'ruby-debug' + end + = link_to 'Learn More: Groups', './groups.html' + + .bullet + .description + After adding a dependency, if it is not yet + installed, install it + .how + :code + $ bundle install + .notes + This will update all dependencies in your + Gemfile to the latest versions that do not + conflict with other dependencies diff --git a/source/v1.11/rationale.haml b/source/v1.11/rationale.haml new file mode 100644 index 0000000000..ff935ea63a --- /dev/null +++ b/source/v1.11/rationale.haml @@ -0,0 +1,427 @@ +#intro + If you just want to know our recommended workflow, and don't care about the rationale, feel + free to jump to the summary below. +%br + +#standalone + %h2#bundlers-purpose-and-rationale + Bundler's Purpose and Rationale + %p + First, you declare these dependencies in a file at the root of your application, called + Gemfile. It looks something like this: + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'rails', '4.1.0.rc2' + gem 'rack-cache' + gem 'nokogiri', '~> 1.6.1' + + %p + This Gemfile says a few things. First, it says that bundler should look for gems + declared in the Gemfile at https://rubygems.org by default. If some + of your gems need to be fetched from a private gem server, this default source can be overridden + for those gems. + + %p + Next, you declare a few dependencies: + + %ul + %li on version 4.1.0.rc2 of rails + %li on any version of rack-cache + %li on a version of nokogiri that is >= 1.6.1 but < 1.7.0 + + %p + After declaring your first set of dependencies, you tell bundler to go get them: + + :code + $ bundle install # 'bundle' is a shortcut for 'bundle install' + + %p + Bundler will connect to rubygems.org (and any other sources that you declared), + and find a list of all of the required gems that meet the requirements you specified. Because + all of the gems in your Gemfile have dependencies of their own (and some of + those have their own dependencies), running bundle install on the + Gemfile above will install quite a few gems. + + :code + $ bundle install + Fetching gem metadata from https://rubygems.org/......... + Fetching additional metadata from https://rubygems.org/.. + Resolving dependencies... + Using rake 10.3.1 + Using json 1.8.1 + Installing minitest 5.3.3 + Installing i18n 0.6.9 + Installing thread_safe 0.3.3 + Installing builder 3.2.2 + Installing rack 1.5.2 + Installing erubis 2.7.0 + Installing mime-types 1.25.1 + Using bundler 1.6.2 + Installing polyglot 0.3.4 + Installing arel 5.0.1.20140414130214 + Installing hike 1.2.3 + Installing mini_portile 0.5.3 + Installing multi_json 1.9.3 + Installing thor 0.19.1 + Installing tilt 1.4.1 + Installing tzinfo 1.1.0 + Installing rack-test 0.6.2 + Installing rack-cache 1.2 + Installing treetop 1.4.15 + Installing sprockets 2.12.1 + Installing activesupport 4.1.0.rc2 + Installing mail 2.5.4 + Installing actionview 4.1.0.rc2 + Installing activemodel 4.1.0.rc2 + Installing actionpack 4.1.0.rc2 + Installing activerecord 4.1.0.rc2 + Installing actionmailer 4.1.0.rc2 + Installing sprockets-rails 2.0.1 + Installing railties 4.1.0.rc2 + Installing rails 4.1.0.rc2 + Installing nokogiri 1.6.1 + Your bundle is complete! + Use `bundle show [gemname]` to see where a bundled gem is installed. + + %p + If any of the needed gems are already installed, Bundler will use them. After installing + any needed gems to your system, bundler writes a snapshot of all of the gems and + versions that it installed to Gemfile.lock. + + %h2#setting-up-your-application-to-use-bundler + Setting Up Your Application to Use Bundler + + %p + Bundler makes sure that Ruby can find all of the gems in the Gemfile + (and all of their dependencies). If your app is a Rails 3+ app, your default application + already has the code necessary to invoke bundler. If it is a Rails 2.3 app, please see + Setting up Bundler in Rails 2.3. + + %p + For another kind of application (such as a Sinatra application), you will need to set up + bundler before trying to require any gems. At the top of the first file that your + application loads (for Sinatra, the file that calls require 'sinatra'), put + the following code: + + :code + # lang: ruby + require 'rubygems' + require 'bundler/setup' + + %p + This will automatically discover your Gemfile, and make all of the gems in + your Gemfile available to Ruby (in technical terms, it puts the gems "on the + load path"). You can think of it as an adding some extra powers to require + 'rubygems'. + + %p + Now that your code is available to Ruby, you can require the gems that you need. For + instance, you can require 'sinatra'. If you have a lot of dependencies, you + might want to say "require all of the gems in my Gemfile". To do this, put + the following code immediately following require 'bundler/setup': + + :code + # lang: ruby + Bundler.require(:default) + + For our example Gemfile, this line is exactly equivalent to: + + :code + # lang: ruby + require 'rails' + require 'rack-cache' + require 'nokogiri' + + %p + Astute readers will notice that the correct way to require the rack-cache + gem is require 'rack/cache', not require 'rack-cache'. To tell + bundler to use require 'rack/cache', update your Gemfile: + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'rails', '4.1.0.rc2' + gem 'rack-cache', require: 'rack/cache' + gem 'nokogiri', '~> 1.6.1' + + %p + For such a small Gemfile, we'd advise you to skip + Bundler.require and just require the gems by hand (especially given the + need to put in a :require directive in the Gemfile). For much + larger Gemfiles, using Bundler.require allows you to skip + repeating a large stack of requirements. + + %h2#checking-your-code-into-version-control + Checking Your Code into Version Control + + %p + After developing your application for a while, check in the application together with + the Gemfile and Gemfile.lock snapshot. Now, your repository + has a record of the exact versions of all of the gems that you used the last time you + know for sure that the application worked. Keep in mind that while your + Gemfile lists only three gems (with varying degrees of version strictness), + your application depends on dozens of gems, once you take into consideration all of the + implicit requirements of the gems you depend on. + + %p + This is important: the Gemfile.lock makes your application a single + package of both your own code and the third-party code it ran the last time you know for + sure that everything worked. Specifying exact versions of the third-party code + you depend on in your Gemfile would not provide the same guarantee, because + gems usually declare a range of versions for their dependencies. + + %p + The next time you run bundle install on the same machine, bundler will see + that it already has all of the dependencies you need, and skip the installation process. + + %p + Do not check in the .bundle directory, or any of the files inside it. Those + files are specific to each particular machine, and are used to persist installation options + between runs of the bundle install command. + + %p + If you have run bundle pack, the gems (although not the git gems) required + by your bundle will be downloaded into vendor/cache. Bundler can run without + connecting to the internet (or the RubyGems server) if all the gems you need are present + in that folder and checked in to your source control. This is an optional + step, and not recommended, due to the increase in size of your source control repository. + + %h2#sharing-your-application-with-other-developers + Sharing Your Application With Other Developers + + %p + When your co-developers (or you on another machine) check out your code, it will come + with the exact versions of all the third-party code your application used on the machine + that you last developed on (in the Gemfile.lock). When **they** run + bundle install, bundler will find the Gemfile.lock and skip + the dependency resolution step. Instead, it will install all of the same gems that you + used on the original machine. + + %p + In other words, you don't have to guess which versions of the dependencies you should + install. In the example we've been using, even though rack-cache declares a + dependency on rack >= 0.4, we know for sure it works with rack + 1.5.2. Even if the Rack team releases rack 1.5.3, bundler will + always install 1.5.2, the exact version of the gem that we know works. This + relieves a large maintenance burden from application developers, because all machines + always run the exact same third-party code. + + %h2#updating-a-dependency + Updating a Dependency + + %p + Of course, at some point, you might want to update the version of a particular + dependency your application relies on. For instance, you might want to update + rails to 4.1.0 final. Importantly, just because you're + updating one dependency, it doesn't mean you want to re-resolve all of your dependencies + and use the latest version of everything. In our example, you only have three + dependencies, but even in this case, updating everything can cause complications. + + %p + To illustrate, the rails 4.1.0.rc2 gem depends on actionpack + 4.1.0.rc2 gem, which depends on rack ~> 1.5.2 (which means >= + 1.5.2 and < 1.6.0). The rack-cache gem depends on + rack >= 0.4. Let's assume that the rails 4.1.0 final gem also + depends on rack ~> 1.5.2, and that since the release of rails + 4.1.0, the Rack team released rack 1.5.3. + + %p + If we naïvely update all of our gems in order to update Rails, we'll get rack + 1.5.3, which satisfies the requirements of both rails 4.1.0 and + rack-cache. However, we didn't specifically ask to update + rack-cache, which may not be compatible with rack 1.5.3 (for + whatever reason). And while an update from rack 1.5.2 to rack + 1.5.3 probably won't break anything, similar scenarios can happen that involve + much larger jumps. (see [1] below for a larger discussion) + + %p + In order to avoid this problem, when you update a gem, bundler will not update a + dependency of that gem if another gem still depends on it. In this example, since + rack-cache still depends on rack, bundler will not update the + rack gem. This ensures that updating rails doesn't + inadvertently break rack-cache. Since rails 4.1.0's dependency + actionpack 4.1.0 remains compatible with rack 1.5.2, bundler + leaves it alone, and rack-cache continues to work even in the face of an + incompatibility with rack 1.5.3. + + %p + Since you originally declared a dependency on rails 4.1.0.rc2, if you want + to update to rails 4.1.0, simply update your Gemfile to + gem 'rails', '4.1.0' and run: + + :code + $ bundle install + + %p + As described above, the bundle install command always does a conservative + update, refusing to update gems (or their dependencies) that you have not explicitly + changed in the Gemfile. This means that if you do not modify + rack-cache in your Gemfile, bundler will treat it **and its + dependencies** (rack) as a single, unmodifiable unit. If rails + 3.0.0 was incompatible with rack-cache, bundler will report a + conflict between your snapshotted dependencies (Gemfile.lock) and your + updated Gemfile. + + %p + If you update your Gemfile, and your system already has all of the needed + dependencies, bundler will transparently update the Gemfile.lock when you + boot your application. For instance, if you add mysql to your + Gemfile, and have already installed it in your system, you can boot your + application without running bundle install, and bundler will persist the + "last known good" configuration to the Gemfile.lock snapshot. + + %p + This can come in handy when adding or updating gems with minimal dependencies (database + drivers, wirble, ruby-debug). It will probably fail if you + update gems with significant dependencies (rails), or that a lot of gems + depend on (rack). If a transparent update fails, your application will fail + to boot, and bundler will print out an error instructing you to run bundle + install. + + %h2#updating-a-gem-without-modyfying-the-gemfile + Updating a Gem Without Modifying the Gemfile + + %p + Sometimes, you want to update a dependency without modifying the Gemfile. For example, + you might want to update to the latest version of rack-cache. Because you + did not declare a specific version of rack-cache in the + Gemfile, you might want to periodically get the latest version of + rack-cache. To do this, you want to use the bundle update + command: + + :code + $ bundle update rack-cache + + %p + This command will update rack-cache and its dependencies to the latest + version allowed by the Gemfile (in this case, the latest version + available). It will not modify any other dependencies. + + %p + It will, however, update dependencies of other gems if necessary. For instance, if the + latest version of rack-cache specifies a dependency on rack >= + 1.5.2, bundler will update rack to 1.5.2 even though + you have not asked bundler to update rack. If bundler needs to update a + gem that another gem depends on, it will let you know after the update has completed. + + %p + If you want to update every gem in the Gemfile to the latest possible versions, run: + + :code + $ bundle update + + %p + This will resolve dependencies from scratch, ignoring the Gemfile.lock. If + you do this, keep git reset --hard and your test suite in your back pocket. + Resolving all dependencies from scratch can have surprising results, especially if a + number of the third-party packages you depend on have released new versions since you + last did a full update. + + %h2#summary + Summary + %h2 A Simple Bundler Workflow + + %ul + %li + %p + When you first create a Rails application, it already comes with a + Gemfile. For another kind of application (such as Sinatra), run: + + :code + $ bundle init + + %p + The bundle init command creates a simple Gemfile which you + can edit. + + %li + %p + Next, add any gems that your application depends on. If you care which version of a + particular gem that you need, be sure to include an appropriate version restriction: + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'sinatra', '~> 1.3.6' + gem 'rack-cache' + gem 'rack-bug' + + %li + %p + If you don't have the gems installed in your system yet, run: + + :code + $ bundle install + + %li + %p + To update a gem's version requirements, first modify the Gemfile: + + :code + # lang: ruby + source 'https://rubygems.org' + + gem 'sinatra', '~> 1.4.5' + gem 'rack-cache' + gem 'rack-bug' + + %p + and then run: + + :code + $ bundle install + + %li + %p + If bundle install reports a conflict between your Gemfile + and Gemfile.lock, run: + + :code + $ bundle update sinatra + + %p + This will update just the Sinatra gem, as well as any of its dependencies. + + %li + %p + To update all of the gems in your Gemfile to the latest possible + versions, run: + + :code + $ bundle update + + %li + Whenever your Gemfile.lock changes, always check it in to version + control. It keeps a history of the exact versions of all third-party code that you + used to successfully run your application. + + %li + %p + When deploying your code to a staging or production server, first run your tests (or + boot your local development server), make sure you have checked in your + Gemfile.lock to version control. On the remote server, run: + + :code + $ bundle install --deployment + + %h2#notes + Notes + + %p + [1] For instance, if rails 4.1.0 depended on rack 2.0, that + gem would still satisfy the requirement of rack-cache, which declares + >= 0.4 as a dependency. Of course, you could argue that + rack-cache is silly for depending on open-ended versions, but these + situations exist (extensively) in the wild, and projects often find themselves between a + rock and a hard place when deciding what version to depend on. Constrain the dependency + too much (rack =1.5.1) and you make it hard to use your project in other + compatible projects. Constrain it too little (rack >= 1.0) and a new + release of Rack may break your code. Using dependencies like rack ~> 1.5.2 + and versioning code in a SemVer compliant way mostly solves this problem, but it assumes + universal compliance. Since RubyGems has over 100,000 packages, this assumption simply + doesn't hold in practice. diff --git a/source/v1.11/rubygems.haml b/source/v1.11/rubygems.haml new file mode 100644 index 0000000000..b57581a3aa --- /dev/null +++ b/source/v1.11/rubygems.haml @@ -0,0 +1,51 @@ +%h2 Using Bundler with Rubygem gemspecs + +.contents + .bullet + .description + If you're creating a gem from scratch, you can use bundler's built in gem skeleton to create a base gem for you to edit. + .how + :code + $ bundle gem my_gem + .notes + This will create a new directory named my_gem with your new gem skeleton. + + .bullet + .description + If you already have a gem with a gemspec, you can generate a Gemfile for your gem. + :code + $ bundle init + .notes + Then, add the following to your new Gemfile + :code + # lang: ruby + gemspec + + .bullet + .description + Runtime dependencies in your gemspec are treated like base dependencies, and development dependencies are added by default to the group, :development. You can change that group with the :development_group option + :code + # lang: ruby + gemspec :development_group => :dev + + .bullet + .description + As well, you can point to a specific gemspec using :path. If your gemspec is in /gemspec/path, use + :code + # lang: ruby + gemspec :path => '/gemspec/path' + + .bullet + .description + If you have multiple gemspecs in the same directory, specify which one you'd like to reference using :name + :code + # lang: ruby + gemspec :name => 'my_awesome_gem' + .notes + This will use my_awesome_gem.gemspec + + .bullet + .description + That's it! Use bundler when developing your gem, and otherwise, use gemspecs normally! + :code + $ gem build my_gem.gemspec diff --git a/source/v1.11/rubymotion.haml b/source/v1.11/rubymotion.haml new file mode 100644 index 0000000000..8d3cbdc3d1 --- /dev/null +++ b/source/v1.11/rubymotion.haml @@ -0,0 +1,36 @@ +%h2 Using Bundler with RubyMotion +.contents + .bullet + .description + If you don't have a RubyMotion app yet, generate one. + :code + $ motion create myapp + $ cd myapp + .bullet + .description + You'll need to create a Gemfile. Here we're using bubblewrap. + :code + # lang: ruby + gem 'bubble-wrap' + + .bullet + .description + Then, set up your Rakefile to require your bundled gems at compile time. + Add this to the top of the file, right beneath the line `require 'motion/project'` + :code + # lang: ruby + require 'bundler' + + Bundler.require + + .bullet + .description + Next, install your dependencies: + :code + $ bundle install + + .bullet + .description + Now you can just compile your app as normal. + :code + $ bundle exec rake diff --git a/source/v1.11/sinatra.haml b/source/v1.11/sinatra.haml new file mode 100644 index 0000000000..f5d934182d --- /dev/null +++ b/source/v1.11/sinatra.haml @@ -0,0 +1,28 @@ +%h2 Using Bundler with Sinatra + +.contents + .bullet + .description + To use bundler with a Sinatra application, you only need to do two things. First, create a Gemfile. + :code + # lang: ruby + gem 'sinatra' + + .bullet + .description + Then, set up your config.ru file to load the bundle before it loads your Sinatra app. + :code + # lang: ruby + require 'rubygems' + require 'bundler' + + Bundler.require + + require './my_sinatra_app' + run MySinatraApp + + .bullet + .description + Start your development server with rackup, and Sinatra will be loaded via Bundler. + :code + $ bundle exec rackup diff --git a/source/v1.11/updating_gems.haml b/source/v1.11/updating_gems.haml new file mode 100644 index 0000000000..37fc25ead7 --- /dev/null +++ b/source/v1.11/updating_gems.haml @@ -0,0 +1,116 @@ +%h2 Updating Gems +.contents + .bullet + .description + %h3#updating-a-dependency + Updating a Dependency + + %p.description + Of course, at some point, you might want to update the version of a particular + dependency your application relies on. For instance, you might want to update + rails to 3.0.0 final. Importantly, just because you're + updating one dependency, it doesn't mean you want to re-resolve all of your dependencies + and use the latest version of everything. In our example, you only have three + dependencies, but even in this case, updating everything can cause complications. + + %p.description + To illustrate, the rails 3.0.0.rc gem depends on actionpack + 3.0.0.rc gem, which depends on rack ~> 1.2.1 (which means >= + 1.2.1 and < 1.3.0). The rack-cache gem depends on + rack >= 0.4. Let's assume that the rails 3.0.0 final gem also + depends on rack ~> 1.2.1, and that since the release of rails + 3.0.0, the Rack team released rack 1.2.2. + + %p.description + If we naïvely update all of our gems in order to update Rails, we'll get rack + 1.2.2, which satisfies the requirements of both rails 3.0.0 and + rack-cache. However, we didn't specifically ask to update + rack-cache, which may not be compatible with rack 1.2.2 (for + whatever reason). And while an update from rack 1.2.1 to rack + 1.2.2 probably won't break anything, similar scenarios can happen that involve + much larger jumps. (see [1] below for a larger discussion) + + %p.description + In order to avoid this problem, when you update a gem, bundler will not update a + dependency of that gem if another gem still depends on it. In this example, since + rack-cache still depends on rack, bundler will not update the + rack gem. This ensures that updating rails doesn't + inadvertently break rack-cache. Since rails 3.0.0's dependency + actionpack 3.0.0 remains compatible with rack 1.2.1, bundler + leaves it alone, and rack-cache continues to work even in the face of an + incompatibility with rack 1.2.2. + + %p.description + Since you originally declared a dependency on rails 3.0.0.rc, if you want + to update to rails 3.0.0, simply update your Gemfile to + gem 'rails', '3.0.0' and run: + + :code + $ bundle install + + %p.description + As described above, the bundle install command always does a conservative + update, refusing to update gems (or their dependencies) that you have not explicitly + changed in the Gemfile. This means that if you do not modify + rack-cache in your Gemfile, bundler will treat it **and its + dependencies** (rack) as a single, unmodifiable unit. If rails + 3.0.0 was incompatible with rack-cache, bundler will report a + conflict between your snapshotted dependencies (Gemfile.lock) and your + updated Gemfile. + + %p.description + If you update your Gemfile, and your system already has all of the needed + dependencies, bundler will transparently update the Gemfile.lock when you + boot your application. For instance, if you add mysql to your + Gemfile, and have already installed it in your system, you can boot your + application without running bundle install, and bundler will persist the + "last known good" configuration to the Gemfile.lock snapshot. + + %p.description + This can come in handy when adding or updating gems with minimal dependencies (database + drivers, wirble, ruby-debug). It will probably fail if you + update gems with significant dependencies (rails), or that a lot of gems + depend on (rack). If a transparent update fails, your application will fail + to boot, and bundler will print out an error instructing you to run bundle + install. + + .bullet + .description + %h3#updating-a-gem-without-modifying-the-gemfile + Updating a Gem Without Modifying the Gemfile + + %p + Sometimes, you want to update a dependency without modifying the Gemfile. For example, + you might want to update to the latest version of rack-cache. Because you + did not declare a specific version of rack-cache in the + Gemfile, you might want to periodically get the latest version of + rack-cache. To do this, you want to use the bundle update + command: + + :code + $ bundle update rack-cache + + %p + This command will update rack-cache and its dependencies to the latest + version allowed by the Gemfile (in this case, the latest version + available). It will not modify any other dependencies. + + %p + It will, however, update dependencies of other gems if necessary. For instance, if the + latest version of rack-cache specifies a dependency on rack >= + 1.2.2, bundler will update rack to 1.2.2 even though + you have not asked bundler to update rack. If bundler needs to update a + gem that another gem depends on, it will let you know after the update has completed. + + %p + If you want to update every gem in the Gemfile to the latest possible versions, run: + + :code + $ bundle update + + %p + This will resolve dependencies from scratch, ignoring the Gemfile.lock. If + you do this, keep git reset --hard and your test suite in your back pocket. + Resolving all dependencies from scratch can have surprising results, especially if a + number of the third-party packages you depend on have released new versions since you + last did a full update. diff --git a/source/v1.11/whats_new.haml b/source/v1.11/whats_new.haml new file mode 100644 index 0000000000..0552610ad1 --- /dev/null +++ b/source/v1.11/whats_new.haml @@ -0,0 +1,39 @@ += partial "shared/whats_new" + +%h2#version111 What's New in v1.11 + +%h2#version110 What's New in v1.10 + +.contents + .bullet + .description + %p + Bundler 1.10 comes with a new `lock` command, support for inline gemfiles in scripts, the ability to disable post-install messages, optional groups, conditional gem installation, dramatically improved `outdated` output, and the option to force installed gems to be downloaded and installed again. + %p + In this section, you’ll find the major features introduced in this release. All the changes are documented in the Bundler 1.11 changelog. + = link_to 'Full 1.10 changelog', 'https://github.com/bundler/bundler/blob/1-11-stable/CHANGELOG.md' + +%h2#error-messages Improved error messages + +.contents + .bullet + .description + %p + Bundler now provides more helpful error messages in 90% of known error cases, avoiding showing a backtrace whenever possible. + +%h2#git-credentials Git Credentials + +.contents + .bullet + .description + %p + Bundler now allows specifying custom git credentials via bundle config. + +.contents + .bullet + .description + Bundler 1.11 also includes: + %ul + %li faster dependency resolution + %li timeouts and retries are now configurable + = link_to 'Full 1.10 changelog', 'https://github.com/bundler/bundler/blob/1-10-stable/CHANGELOG.md' From 330e947e79e045a8b9bec54687f316598a578c0c Mon Sep 17 00:00:00 2001 From: Andre Arko Date: Sun, 13 Dec 2015 11:35:30 +0800 Subject: [PATCH 07/10] add 1.11 to the layout etc --- Rakefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Rakefile b/Rakefile index 64c6578043..735d1059c0 100644 --- a/Rakefile +++ b/Rakefile @@ -9,7 +9,7 @@ task :update_vendor => ["vendor/bundler"] do Dir.chdir("vendor/bundler") { sh "git fetch" } end -VERSIONS = %w(v1.0 v1.1 v1.2 v1.3 v1.5 v1.6 v1.7 v1.8 v1.9 v1.10).freeze +VERSIONS = %w(v1.0 v1.1 v1.2 v1.3 v1.5 v1.6 v1.7 v1.8 v1.9 v1.10 v1.11).freeze desc "Print the Bundler versions the site documents" task :versions do puts VERSIONS.join(' ') From 5253e518551e1323aa8f8ccf1f13957c27ed94a8 Mon Sep 17 00:00:00 2001 From: Andre Arko Date: Sun, 13 Dec 2015 11:35:45 +0800 Subject: [PATCH 08/10] =?UTF-8?q?update=201.11=20what=E2=80=99s=20new?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/v1.11/whats_new.haml | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/source/v1.11/whats_new.haml b/source/v1.11/whats_new.haml index 0552610ad1..bb9dcce1e5 100644 --- a/source/v1.11/whats_new.haml +++ b/source/v1.11/whats_new.haml @@ -2,38 +2,38 @@ %h2#version111 What's New in v1.11 -%h2#version110 What's New in v1.10 +%h3#error-messages Improved permissions errors .contents .bullet .description %p - Bundler 1.10 comes with a new `lock` command, support for inline gemfiles in scripts, the ability to disable post-install messages, optional groups, conditional gem installation, dramatically improved `outdated` output, and the option to force installed gems to be downloaded and installed again. - %p - In this section, you’ll find the major features introduced in this release. All the changes are documented in the Bundler 1.11 changelog. - = link_to 'Full 1.10 changelog', 'https://github.com/bundler/bundler/blob/1-11-stable/CHANGELOG.md' + Bundler now provides a helpful error message for all sorts of permissions errors that used to cause an exception and show a backtrace. -%h2#error-messages Improved error messages +%h3#git-credentials Git Credentials .contents .bullet .description %p - Bundler now provides more helpful error messages in 90% of known error cases, avoiding showing a backtrace whenever possible. + Bundler now allows specifying custom git credentials via bundle config. -%h2#git-credentials Git Credentials +%h3#lock-update Update gems without installing them .contents .bullet .description %p - Bundler now allows specifying custom git credentials via bundle config. + It is now possible to update the locked version of a gem without also installing it, by running bundle lock --update [GEM [GEM ...]] to update the versions of some gems (or all gems). .contents .bullet .description Bundler 1.11 also includes: %ul - %li faster dependency resolution - %li timeouts and retries are now configurable - = link_to 'Full 1.10 changelog', 'https://github.com/bundler/bundler/blob/1-10-stable/CHANGELOG.md' + %li up to 25x faster dependency resolution + %li vastly improved resolver conflict messages + %li configurable timeouts and retries + %li configurable git remote and gem server for `rake release` + %li many, many, many bugfixes + = link_to 'Full 1.11 changelog', 'https://github.com/bundler/bundler/blob/1-11-stable/CHANGELOG.md' From 8375a6bae63d73747ef3df55eb7af6564c9f9b2e Mon Sep 17 00:00:00 2001 From: Andre Arko Date: Sun, 13 Dec 2015 13:20:24 +0800 Subject: [PATCH 09/10] Add bin/rake --- bin/rake | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100755 bin/rake diff --git a/bin/rake b/bin/rake new file mode 100755 index 0000000000..26c7a2d5b5 --- /dev/null +++ b/bin/rake @@ -0,0 +1,16 @@ +#!/usr/bin/env ruby +# +# This file was generated by Bundler. +# +# The application 'rake' is installed as part of a gem, and +# this file is here to facilitate running it. +# + +require 'pathname' +ENV['BUNDLE_GEMFILE'] ||= File.expand_path("../../Gemfile", + Pathname.new(__FILE__).realpath) + +require 'rubygems' +require 'bundler/setup' + +load Gem.bin_path('rake', 'rake') From 84499adbb5d0c322f213b69f05f6a433e98a488c Mon Sep 17 00:00:00 2001 From: Shim Won Date: Sun, 13 Dec 2015 17:45:30 +0900 Subject: [PATCH 10/10] Copy file from 1.10 --- source/v1.11/bundle_binstubs.haml | 12 +- source/v1.11/bundle_check.haml | 20 +- source/v1.11/bundle_clean.haml | 10 +- source/v1.11/bundle_config.haml | 253 +++++++++--------- source/v1.11/bundle_console.haml | 7 +- source/v1.11/bundle_exec.haml | 24 +- source/v1.11/bundle_gem.haml | 22 +- source/v1.11/bundle_help.haml | 4 +- source/v1.11/bundle_init.haml | 12 +- source/v1.11/bundle_inject.haml | 8 +- source/v1.11/bundle_install.haml | 98 ++++--- source/v1.11/bundle_open.haml | 6 +- source/v1.11/bundle_outdated.haml | 18 +- source/v1.11/bundle_package.haml | 57 ++-- source/v1.11/bundle_platform.haml | 13 +- source/v1.11/bundle_show.haml | 10 +- source/v1.11/bundle_update.haml | 159 ++++++------ source/v1.11/bundle_version.haml | 2 +- source/v1.11/bundle_viz.haml | 22 +- source/v1.11/bundler_setup.haml | 68 +++-- source/v1.11/bundler_sharing.haml | 71 +++-- source/v1.11/bundler_workflow.haml | 118 ++++----- source/v1.11/commands.haml | 38 +-- source/v1.11/deploying.haml | 158 ++++++------ source/v1.11/faq.haml | 177 ++++++------- source/v1.11/gemfile.haml | 119 +++++---- source/v1.11/gemfile_ruby.haml | 26 +- source/v1.11/git.haml | 129 +++++----- source/v1.11/groups.haml | 94 ++++--- source/v1.11/index.haml | 89 ++++--- source/v1.11/rails23.haml | 44 ++-- source/v1.11/rails3.haml | 42 ++- source/v1.11/rationale.haml | 401 +++++++++++++++-------------- source/v1.11/rubygems.haml | 20 +- source/v1.11/rubymotion.haml | 14 +- source/v1.11/sinatra.haml | 8 +- source/v1.11/updating_gems.haml | 153 +++++------ 37 files changed, 1246 insertions(+), 1280 deletions(-) diff --git a/source/v1.11/bundle_binstubs.haml b/source/v1.11/bundle_binstubs.haml index 1bd4e824ab..e79189f6ec 100644 --- a/source/v1.11/bundle_binstubs.haml +++ b/source/v1.11/bundle_binstubs.haml @@ -3,16 +3,16 @@ .contents .bullet .description - Installs the binstubs of the listed gem + 나열된 gem의 binstubs를 설치 :code $ bundle binstubs [GEM] [--force] [--path=PATH] .notes %p - Options: + 옵션: %p - --force: Overwrite existing binstubs if they exist. + --force: 이미 binstubs가 있다면 덮어쓰기 %p - --path: Binstub destination directory (default bin) + --path: Binstub을 놓을 디렉터리 (bin이 기본 값) .description - Generate binstubs for executables in [GEM]. Binstubs are put into bin, - or the --binstubs directory if one has been set. + [GEM] 안의 실행파일의 binstubs를 생성합니다. Binstubs는 bin 안에 들어가거나, + \--path 가 지정되어 있으면 지정한 binstubs 디렉터리에 들어갑니다. diff --git a/source/v1.11/bundle_check.haml b/source/v1.11/bundle_check.haml index 606f48b541..3031edd56e 100644 --- a/source/v1.11/bundle_check.haml +++ b/source/v1.11/bundle_check.haml @@ -3,21 +3,21 @@ .contents .bullet .description - Checks if the dependencies listed in Gemfile are satisfied by currently installed gems + 현재 설치된 gem이 Gemfile의 의존성을 만족하는지 확인합니다. :code $ bundle check [--dry-run] [--gemfile=FILE] [--path=PATH] .notes %p - Options: + 옵션: %p - --dry-run: Locks the Gemfile. + --dry-run: Gemfile을 고정합니다. %p - --gemfile: Use the specified gemfile instead of Gemfile. + --gemfile: Gemfile 대신 특정 gemfile을 사용합니다. %p - --path: Specify a different path than the system default - ($BUNDLE_PATH or $GEM_HOME). Bundler will remember this value for future - installs on this machine. + --path: 시스템 기본 값($BUNDLE_PATH 이나 $GEM_HOME) 대신 + 다른 경로를 지정합니다. 번들러는 이 값을 기억했다가 다음 설치에서도 + 사용합니다. .description - Check searches the local machine for each of the gems requested in the Gemfile. If - all gems are found, Bundler prints a success message and exits with a status of 0. - If not, the first missing gem is listed and Bundler exits status 1. + check는 Gemfile에서 요청한 gem을 로컬 기기에서 찾습니다. 모든 gem이 있다면 + 번들러는 성공 메시지를 출력하고 상태 코드 0으로 종료합니다. 없다면 가장 + 처음에 없는 gem이 나열되며 상태 코드 1로 종료합니다. diff --git a/source/v1.11/bundle_clean.haml b/source/v1.11/bundle_clean.haml index 9ca8ef3993..6d93719c2e 100644 --- a/source/v1.11/bundle_clean.haml +++ b/source/v1.11/bundle_clean.haml @@ -3,14 +3,14 @@ .contents .bullet .description - Cleans up unused gems in your bundler directory + 번들러 디렉터리의 사용하지 않는 gem을 청소합니다. :code $ bundle clean [--dry-run] [--force] .notes %p - Options: + 옵션: %p - --dry-run: Only print out changes, do not actually clean - gems + --dry-run: 변경을 출력하기만 하고, 실제로 gem을 청소하지는 + 않습니다. %p - --force: Forces clean even if --path is set + --force: --path가 설정되어 있어도 강제로 청소합니다. diff --git a/source/v1.11/bundle_config.haml b/source/v1.11/bundle_config.haml index ae17158ca1..6683457c80 100644 --- a/source/v1.11/bundle_config.haml +++ b/source/v1.11/bundle_config.haml @@ -3,273 +3,250 @@ .contents .bullet .description - Retrieve or set a configuration value + 설정 값을 검색하거나 설정합니다. :code $ bundle config [NAME [VALUE]] [--local] [--global] [--delete] .notes %p - Options: + 옵션: %p - --local: Get/set local configuration + --local: 로컬 설정을 읽고 씁니다. %p - --global: Get/set global configuration + --global: 전역 설정을 읽고 씁니다. %p - --delete: Delete NAME value + --delete: NAME 값을 제거합니다. .description %p - Retrieves or sets a configuration value. If only parameter is provided, - retrieve the value. If two parameters are provided, replace the existing - value with the newly provided one. + 설정 값을 검색하거나 설정합니다. 하나의 매개변수만 주어지면 값을 검색합니다. + 두 개의 매개변수가 주어지면 기존의 값을 주어진 값으로 대체합니다. %p - By default, setting a configuration value sets it for all projects on - the machine. + 기본 값으로 설정 값을 설정하면 기기의 모든 프로젝트에 설정됩니다. %p - If a global setting is superceded by local configuration, this command - will show the current value, as well as any superceded values and where - they were specified. + 전역 설정이 로컬 설정에 의해 대체된다면 이 명령어는 현재 값뿐만 아니라 + 대체 값과 그 값들이 어디에 지정되었는지를 보여줍니다. .bullet#config .description - Get your bundle configuration. + 번들 설정을 읽습니다. .how :code $ bundle config .notes - Executing bundle config with no parameters will print a - list of all bundler configuration for the current bundle, and where - that configuration was set. + 매개변수 없이 bundle config을 실행하면 현재 번들을 위한 + 모든 번들러 설정과 그 값이 어디에서 설정되었는지를 출력합니다. .bullet#get .description - Get your bundle configuration for NAME variable. + NAME 변수의 번들 설정을 읽습니다. .how :code $ bundle config NAME .notes - Will print the value of that configuration setting for - NAME, and where it was set. Will print both local and - global configuration. + NAME의 설정된 값과 그 값이 어디에서 설정되었는지를 출력합니다. + 로컬과 전역 모두 출력합니다. .bullet#set .description - Set your bundle configuration for NAME variable to - VALUE. + 번들 설정 변수 NAME에 VALUE를 씁니다. .how :code $ bundle config NAME VALUE .notes - Will set NAME to VALUE for all bundles - executed as the current user (i.e. global setting). The configuration - will be stored in ~/.bundle/config. If NAME - already is set, NAME will be overridden and user will be - warned. + 전역 설정의 경우라면 현재 사용자로서 실행하는 모든 번들에 대해 + NAME에 VALUE를 설정합니다. 설정은 + ~/.bundle/config에 저장됩니다. NAME이 + 이미 설정되어 있다면 경고와 함께 NAME을 덮어 씁니다. .bullet#global .description - Set your bundle global/user configuration for NAME variable - to VALUE. + 전역/사용자 번들 설정 변수 NAME에 VALUE를 씁니다. .how :code $ bundle config --global NAME VALUE .notes - Works the same as the command above. + 위의 명령어와 같은 동작을 합니다. .bullet#local .description - Set your bundle local configuration for NAME variable to - VALUE. + 로컬 번들 설정 변수 NAME에 VALUE를 씁니다. .how :code $ bundle config --local NAME VALUE .notes - Works the same as the two command above but for the local application. - The configuration will be stored in app/.bundle/config. + 위의 명령어와 같은 동작을 하지만 로컬 애플리케이션용입니다. + 설정은 app/.bundle/config에 저장됩니다. .bullet#delete .description - Delete the configuration for NAME in both local and global sources. + 전역과 로컬에서 NAME의 설정을 삭제합니다. .how :code $ bundle config --delete NAME .notes - Will delete the configuration for NAME variable in both local and global sources. Not compatible with --global or --local flag. + 전역과 로컬에서 NAME의 설정 값을 + 삭제합니다. --global이나 --local 플래그와는 호환되지 않습니다. -%h2 Build options +%h2 빌드 옵션 .contents .bullet#build_options .description %p - You can use bundle config to give bundler the flags to - pass to the gem installer every time bundler tries to install a - particular gem. + bundle config는 특정 gem을 설치할 때마다 인스톨러에 플래그를 + 넘겨주는 용도로도 사용할 수 있습니다. %p - A very common example, the mysql gem, requires Snow - Leopard users to pass configuration flags to gem install - to specify where to find the mysql_config executable. + 매우 일반적인 예로 mysql gem은 스노우 레퍼드에서 gem + install을 할 때 mysql_config 실행 파일을 찾기 위한 설정 + 플래그를 필요로 합니다. .how :code $ gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config %p - Since the specific location of that executable can change from machine - to machine, you can specify these flags on a per-machine basis. + mysql_config의 실행 파일의 구체적인 위치가 기기마다 다를 수 + 있으므로 각 기기마다 이 플래그를 지정할 수 있습니다. .how :code $ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config %p - After running this command, every time bundler needs to install the - mysql gem, it will pass along the flags you specified. + 이 명령어를 실행하면 mysql gem을 설치해야 할 때마다 지정한 + 플래그를 함께 넘겨 줍니다. -%h2 Configuration keys +%h2 설정 키 .contents .bullet#configuration_keys .description %p - Configuration keys in bundler have two forms: the canonical form and - the environment variable form. + 번들러에서의 설정 키는 두 가지 양식이 있습니다. 표준 양식과 환경 변수 + 양식입니다. %p - For instance, passing the --without flag to - bundle install prevents Bundler from installing - certain groups specified in the Gemfile. Bundler persists - this value in app/.bundle/config so that calls to - Bundler.setup do not try to find gems from the - Gemfile that you didn't install. Additionally, subsequent - calls to bundle install remember this setting and - skip those groups. + 예를 들어, bundle install에 --without 플래그를 + 넘겨주어 번들러가 Gemfile의 특정 그룹을 설치하지 않도록 할 + 경우 번들러는 이 값을 app/.bundle/config 안에 남겨 두어 + Bundler.setup이 Gemfile에서 설치되지 않은 gem을 + 찾으려 하지 않도록 합니다. 덤으로 bundle install을 또 실행 + 할 때 이 설정을 기억해 두었다가 그 그룹들을 생략합니다. %p - The canonical form of this configuration is "without". To - convert the canonical form to the environment variable form, capitalize - it, and prepend BUNDLE_. The environment variable form of - "without" is BUNDLE_WITHOUT. + 이 설정의 표준 양식은 "without"입니다. 표준 양식에서 환경 + 변수 양식으로 변경하려면 대문자로 바꾸고 앞에 BUNDLE_을 + 붙이세요. "without"의 환경 변수 양식은 + BUNDLE_WITHOUT입니다. -%h2 List of available keys +%h2 가능한 키의 목록 .contents .bullet#available_keys .description %p - The following is a list of all configuration keys and their purpose. - You can learn more about their operation in - bundle install. + 전체 설정 키와 그 기능은 다음과 같습니다. + bundle install을 실행하면 작업에 대해 더 많이 배울 수 있습니다. %ul %li - auto_install (1): Setting auto_install config - to 1 or any other truthy value will enable automatic installing of gems - instead of raising an error. This behavior applies to the following - commands: show, binstubs, + auto_install (1): auto_install 설정을 + 1이나 다른 참 값으로 하면 에러를 일으키는 대신 gem 자동 설치를 + 활성화합니다. 이 행동은 밑의 명령어에 영향을 미칩니다. + show, binstubs, outdated, exec, open, console, license, clean. %li - path (BUNDLE_PATH): The location on disk - to install gems. Defaults to $GEM_HOME in development - and vendor/bundle when --deployment is used. + path (BUNDLE_PATH): gem을 설치할 디스크 + 경로입니다. 개발 환경에서는 $GEM_HOME, + --deployment가 사용되었다면 vendor/bundle이 기본 값입니다. %li - frozen (BUNDLE_FROZEN): Disallow changes to - the Gemfile. Defaults to true when - --deployment is used. + frozen (BUNDLE_FROZEN): Gemfile의 + 변경을 금지합니다. --deployment가 사용되었다면 기본 값은 + true입니다. %li - without (BUNDLE_WITHOUT): A - :-separated list of groups whose gems bundler should not - installer + without (BUNDLE_WITHOUT): 설치하지 말아야 할 + 그룹의 목록입니다. :으로 구분됩니다. %li - bin (BUNDLE_BIN): Install executables from - gems in the bundle to the specified directory. Defaults to - false. + bin (BUNDLE_BIN): 번들 안의 gem에서 실행 파일을 + 특정 디렉터리에 설치합니다. 기본 값은 false입니다. %li - gemfile (BUNDLE_GEMFILE): The name of the - file that bundler should use as the Gemfile. This location - of this file also sets the root of the project, which is used to - resolve relative paths in the Gemfile, among other things. - By default, bundler will search up from the current working directory - until it finds a Gemfile. + gemfile (BUNDLE_GEMFILE): 번들러가 + Gemfile로 사용할 파일의 이름입니다. 이 파일의 위치는 + 프로젝트의 루트도 설정합니다. 프로젝트의 루트는 무엇보다도 + Gemfile의 상대 경로를 확인하는 데 사용됩니다. %li - ssl_ca_cert (BUNDLE_SSL_CA_CERT): - Path to a designated CA certificate file or folder containing multiple - certificates for trusted CAs in PEM format. + ssl_ca_cert (BUNDLE_SSL_CA_CERT): + 지정된 CA 인증서 파일이나 PEM 형식의 신뢰된 CA 인증서가 여럿 들어있는 + 폴더의 경로입니다. %li ssl_client_cert (BUNDLE_SSL_CLIENT_CERT): - Path to a designated file containing a X.509 client certificate - and key in PEM format. + PEM 형식의 X.509 클라이언트 인증서와 키가 들어있는 지정된 파일의 + 경로입니다. %li - cache_path (BUNDLE_CACHE_PATH): The directory - that bundler will place cached gems in when running bundle - package and that bundler will look in when installing with the - --deployment option. + cache_path (BUNDLE_CACHE_PATH): + bundle package를 실행할 때 번들러가 캐시할 gem을 넣을 + 디렉터리입니다. --deployment 옵션으로 설치할 때 번들러가 + 해당 디렉터리를 들여다보게 됩니다. %li disable_multisource (BUNDLE_DISABLE_MULTISOURCE): - When set, Gemfiles containing multiple sources will produce an error - instead of a warning. Use bundle config --delete - disable_multisource to unset. + 이 값이 설정되어 있으면 Gemfile에 여러 소스가 있을 경우 경고 대신 에러를 출력합니다. + bundle config --delete disable_multisource로 해제할 수 + 있습니다. %p - In general, you should set these settings per-application by using the - applicable flag to the bundle install or bundle - package command. + 일반적으로 해당 플래그를 bundle install이나 bundle + package 명령어에 사용함으로써 애플리케이션별 설정을 해야합니다. %p - You can set them globally either via environment variables or - bundle config, whichever is preferable for your setup. If - you use both, environment variables will take preference over global - settings. + 환경 변수나 bundle config 어느 쪽이든 좀 더 상황에 맞는 쪽을 골라 + 전역 설정할 수 있습니다. 양쪽 다 사용한다면 환경 변수가 전역 설정보다 + 우선됩니다. -%h2 Local git repositories +%h2 로컬 git 저장소 .contents .bullet#local_git_repos .description %p - Bundler also allows you to work against a git repository locally - instead of using the remote version. This can be achieved by setting - up a local override: + 번들러는 리모트 버전이 아닌 로컬 git 저장소로 작업하게 할 수도 있습니다. + 이렇게 하려면 로컬 우선으로 설정하실 필요가 있습니다. :code $ bundle config local.GEM_NAME /path/to/local/git/repository %p - For example, in order to use a local Rack repository, a developer - could call: + 예를 들어 로컬 Rack 저장소를 사용하시려면 이렇게 하시면 됩니다. :code $ bundle config local.rack ~/Work/git/rack %p - Now instead of checking out the remote git repository, the local - override will be used. Similar to a path source, every time the local - git repository change, changes will be automatically picked up by - Bundler. This means a commit in the local git repo will update the - revision in the Gemfile.lock to the local git repo - revision. This requires the same attention as git submodules. Before - pushing to the remote, you need to ensure the local override was - pushed, otherwise you may point to a commit that only exists in your - local machine. + 이제 리모트 git 저장소에서 체크아웃 하는 대신, 로컬 저장소가 우선됩니다. + 경로(path) 소스와 비슷하게 로컬 git 저장소가 변경 될 때마다 변경 내용은 + 자동으로 번들러가 반영해줍니다. 이 말은 로컬 git 저장소의 커밋은 + Gemfile.lock 안의 리비전을 로컬 git 저장소의 리비전으로 + 갱신한다는 뜻입니다. 이것은 git 서브모듈을 사용할 때처럼 주의가 + 필요합니다. 리모트에 푸시하기 전에 로컬에 있는 게 전부 푸시되어 있는지 + 확인하셔야 합니다. 그렇지 않으면 로컬 기기에만 있는 커밋을 가리키게 + 됩니다. %p - Bundler does many checks to ensure a developer won't work with - invalid references. Particularly, we force a developer to specify a - branch in the Gemfile in order to use this feature. If the - branch specified in the `Gemfile` and the current branch in the local - git repository do not match, Bundler will abort. This ensures that a - developer is always working against the correct branches, and prevents - accidental locking to a different branch. + 번들러에는 잘못된 참조로 작동하지 않는지 확신하기 위한 많은 확인 과정이 있습니다. + 특히 이 기능을 사용하기 위해서는 Gemfile에서 브랜치를 + 명시해야 합니다. Gemfile 안에 지정되어 있는 브랜치와 로컬 + 저장소의 현재 브랜치가 맞지 않으면 번들러는 실행을 정지합니다. 이것은 + 항상 정확한 브랜치에 대해 작업하고 있는지 확인하고 의도치 않게 다른 + 브랜치를 보는 것을 예방합니다. %p - Finally, Bundler also ensures that the current revision in the - Gemfile.lock exists in the local git repository. By doing - this, Bundler forces you to fetch the latest changes in the remotes. + 마지막으로 번들러는 Gemfile.lock 안의 맞는 리비전이 + 로컬 git 저장소에 있는지도 확인합니다. 이렇게 함으로써 번들러는 + 리모트의 마지막 변경 사항을 가져오도록 합니다. -%h2 Gem Source Mirrors +%h2 gem 소스 미러 .contents .bullet#gem-source-mirrors .description %p - If your environment contains a local mirror of the rubygems.org server, - use the mirror.URL configuration option to supply the URL - of the mirror. At that point, Bundler will download gems and gemspecs - from that mirror instead of the source listed in the Gemfile. + 환경이 rubygems.org 서버의 로컬 미러를 가지고 있다면, + mirror.URL에 미러의 주소를 설정합니다. 그 시점에서 번들러는 + Gemfile 안의 소스 대신, 미러에서 gem과 gemspec을 다운로드 합니다. :code $ bundle config mirror.https://rubygems.org https://localgems.lan diff --git a/source/v1.11/bundle_console.haml b/source/v1.11/bundle_console.haml index 9efd8a0527..33482a42cd 100644 --- a/source/v1.11/bundle_console.haml +++ b/source/v1.11/bundle_console.haml @@ -3,12 +3,15 @@ .contents .bullet .description - Start an interactive Ruby console session in the context of the current bundle + 대화형 루비 콘솔 세션을 현재 번들의 컨텍스트에서 시작합니다. :code $ bundle console [GROUP] .description - bundle console uses irb by default. Alternatives like Pry and Ripl can be used with bundle console by adjusting the console Bundler setting. Also make sure that pry or ripl is in your Gemfile. + bundle console은 기본 값으로 irb를 사용합니다. 번들러 설정 + console을 변경하면 Pry나 Ripl도 bundle console로 + 사용할 수 있습니다. 그런 경우에는 pry나 ripl이 Gemfile에 + 들어있는지도 확인하셔야 합니다. :code $ bundle config console pry $ bundle console diff --git a/source/v1.11/bundle_exec.haml b/source/v1.11/bundle_exec.haml index 3f8de13cd1..b44a67cc10 100644 --- a/source/v1.11/bundle_exec.haml +++ b/source/v1.11/bundle_exec.haml @@ -3,24 +3,24 @@ .contents .bullet .description - Run the command in context of the bundle + 번들의 컨텍스트에서 명령어를 실행합니다. :code $ bundle exec [--keep-file-descriptors] .notes %p - Options: + 옵션: %p - --keep-file-descriptors: For Ruby versions less than 2.0, - keeps non-standard file descriptors on Kernel#exec + --keep-file-descriptors: 2.0 이전의 루비 버전을 위해 + Kernel#exec의 비 표준 파일 디스크립터를 유지합니다. .description - This command executes the command, making all gems specified in the - Gemfile(5) available to require in Ruby programs. + 이 명령어는 Gemfile(5) 안에 지정된 모든 gem을 루비 프로그램에서 + require할 수 있게 만들면서 명령어를 실행합니다. - Essentially, if you would normally have run something like - rspec spec/my_spec.rb, and you want to use the gems specified - in the Gemfile and installed via bundle install, you - should run bundle exec rspec spec/my_spec.rb. + 원래 rspec spec/my_spec.rb처럼 일반적으로 실행하던 명령어를, + Gemfile에 지정되고 bundle install로 설치된 gem을 + 통해 사용하고 싶은 경우는 bundle exec rspec spec/my_spec.rb로 + 실행하셔야 합니다. - Note that bundle exec does not require that an executable is - available on your shell's $PATH. + bundle exec를 하기 위해 실행파일이 셸의 $PATH에서 + 사용 가능할 필요는 없습니다. diff --git a/source/v1.11/bundle_gem.haml b/source/v1.11/bundle_gem.haml index ae8406a0fa..2cfd1fd900 100644 --- a/source/v1.11/bundle_gem.haml +++ b/source/v1.11/bundle_gem.haml @@ -3,31 +3,31 @@ .contents .bullet .description - Creates a skeleton for creating a rubygem + 루비젬을 만들기 위한 뼈대를 생성합니다. :code $ bundle gem GEM [--bin or -b] [--test=TESTFRAMEWORK] [--edit=TEXTEDITOR] [--ext] .notes %p - Options: + 옵션: %p - --bin or -b: Generate a binary for your library. + --bin, -b: 라이브러리를 위한 바이너리를 생성합니다. %p - --coc: Generate a code of conduct file. + --coc: 행동 강령 파일을 생성합니다. %p - --edit: Open generated gemspec in the specified editor (defaults to $EDITOR or $BUNDLER_EDITOR) + --edit: 생성된 gemspec을 특정 편집기에서 엽니다.(기본 값은$EDITOR, $BUNDLER_EDITOR) %p - --ext: Generate a skeleton for a C-extension. + --ext: C 확장기능을 위한 뼈대를 생성합니다. %p - --mit: Generate an MIT license file. + --mit: MIT 라이선스 파일을 만듭니다. %p - --test: Generate a test directory for your library: - rspec is the default, but minitest is also supported. + --test: 라이브러리를 위한 테스트 디렉터리를 생성합니다. + 기본 값은 rspec이지만, minitest도 지원합니다. .notes %p - When run for the first time, bundle gem will ask for your preferences regarding test framework, code of conduct, and MIT license. These preferences will be stored in ~/.bundle/config for future runs. + 처음 실행할 때, bundle gem은 테스트 프레임워크, 행동 강령, MIT 라이선스의 설정을 물어봅니다. 이 설정은 앞으로 실행할 때를 위해 ~/.bundle/config에 저장됩니다. .bullet .description - The generated project will contain all the necessary boilerplate, including a README and a gemspec template. Also included will be a Rakefile with tasks suitable for gem development: + 생성된 프로젝트는 README와 gemspec 템플릿을 포함해 필요한 모든 뼈대를 가지고 있습니다. 또 gem 개발에 필요한 작업도 Rakefile에 넣어줍니다. .how :code $ rake -T diff --git a/source/v1.11/bundle_help.haml b/source/v1.11/bundle_help.haml index fd09a4b50a..0891df4299 100644 --- a/source/v1.11/bundle_help.haml +++ b/source/v1.11/bundle_help.haml @@ -3,8 +3,8 @@ .contents .bullet .description - Displays detailed help for each subcommand on your command line + 각 하위 명령어를 위한 자세한 도움말을 커맨드 라인에 표시합니다. :code $ bundle help .notes - #{ link_to 'View the same man pages here', './man/bundle.1.html'} + #{ link_to '같은 결과의 man 페이지를 여기서 보실 수 있습니다', './man/bundle.1.html'} diff --git a/source/v1.11/bundle_init.haml b/source/v1.11/bundle_init.haml index 18e7d7bd3b..e50b8c500a 100644 --- a/source/v1.11/bundle_init.haml +++ b/source/v1.11/bundle_init.haml @@ -3,15 +3,15 @@ .contents .bullet .description - Generates a Gemfile into the current working directory + 현재 작업 디렉터리에 Gemfile을 생성합니다. :code $ bundle init [--gemspec=FILE] .notes %p - Options: + 옵션: %p - --gemspec: Use the specified .gemspec to create the Gemfile + --gemspec: 지정한 .gemspec으로 Gemfile을 생성합니다. .description - Init generates a default Gemfile in the current working directory. When adding a - Gemfile to a gem with a gemspec, the --gemspec option will automatically add each - dependency listed in the gemspec file to the newly created Gemfile. + 기본 Gemfile을 현재 작업 디렉터리에 생성합니다. gemspec이 이미 있는 gem에 + Gemfile을 추가할 경우, --gemspec 옵션을 통해 새로 생성하는 Gemfile에 + gemspec의 의존성을 자동으로 추가할 수 있습니다. diff --git a/source/v1.11/bundle_inject.haml b/source/v1.11/bundle_inject.haml index 51fd112a33..accecb09fc 100644 --- a/source/v1.11/bundle_inject.haml +++ b/source/v1.11/bundle_inject.haml @@ -3,16 +3,16 @@ .contents .bullet .description - Add the named gem(s), with version requirements, to the resolved Gemfile + 결정된 Gemfile에 gem 이름과 버전을 추가합니다. :code $ bundle inject [GEM] [VERSION] .bullet .description - When injecting a gem, it adds it to both your Gemfile and Gemfile.lock if - it doesn't yet exist in them. Example below: + gem을 주입할 때, Gemfile과 Gemfile.lock에 아직 없는 경우 양쪽에 해당 gem을 추가하게 됩니다. + 밑의 예제를 보세요. :code $ bundle install $ bundle inject 'rack' '> 0' - # Injects rack gem greater than version 0 in your Gemfile and Gemfile.lock + # 버전 0 이상의 rack gem을 Gemfile, Gemfile.lock에 주입 diff --git a/source/v1.11/bundle_install.haml b/source/v1.11/bundle_install.haml index ad8958ec21..2dc339aac5 100644 --- a/source/v1.11/bundle_install.haml +++ b/source/v1.11/bundle_install.haml @@ -3,7 +3,7 @@ .contents .bullet .description - Make sure all dependencies in your Gemfile are available to your application. + 애플리케이션이 Gemfile 안에 있는 의존성을 만족하는지 확인합니다. :code $ bundle install [--binstubs=PATH] [--clean] [--deployment] [--frozen] [--full-index] [--gemfile=FILE] [--local] [--no-cache] @@ -13,110 +13,104 @@ [--trust-policy=SECURITYLEVEL] .notes %p - Options: + 옵션: %p - --binstubs: Generate bin stubs for bundled gems to ./bin + --binstubs: ./bin 폴더에 실행 파일의 스텁을 생성합니다. %p - --clean: Run bundle clean automatically after install + --clean: 설치 후 자동으로 bundle clean을 실행합니다. %p - --deployment: Install using defaults tuned for deployment and CI environments + --deployment: 배포, CI 환경에 최적화된 기본 값으로 설치합니다. %p - --frozen: Do not allow the Gemfile.lock to be updated after this install + --frozen: 이번 설치 이후 Gemfile.lock을 업데이트 할 수 없게 합니다. %p - --full-index: Use the rubygems modern index instead of the API endpoint + --full-index: API 엔드포인트 대신 rubygems의 모던 인덱스를 사용합니다. %p - --gemfile: Use the specified gemfile instead of Gemfile + --gemfile: Gemfile 대신 지정한 젬파일을 사용합니다. %p - --jobs: Install gems using parallel workers. + --jobs: 병렬 워커를 사용해 설치합니다. %p - --local: Do not attempt to fetch gems remotely and use the gem cache instead + --local: 원격에서 gem을 가져오지 않는 대신 캐시된 gem을 사용합니다. %p - --no-cache: Don't update the existing gem cache. + --no-cache: 갱신에 캐시된 gem을 사용하지 않습니다. %p - --no-prune: Don't remove stale gems from the cache. + --no-prune: 캐시에서 오래된 gem을 제거하지 않습니다. %p - --path: Specify a different path than the system default ($BUNDLE_PATH or $GEM_HOME). Bundler will remember this value for future installs on this machine + --path: 시스템 기본 값($BUNDLE_PATH나 $GEM_HOME) 대신 다른 경로를 지정합니다. 번들러는 이 기기에서 이 값을 기억할 것입니다. %p - --quiet: Only output warnings and errors. + --quiet: 경고와 에러만 출력합니다. %p - --retry: Retry network and git requests that have failed. + --retry: 실패한 네트워크, git 요청을 재시도합니다. %p - --shebang: Specify a different shebang executable name than the default (usually 'ruby') + --shebang: 시스템 기본 값(보통 'ruby') 대신 다른 쉬뱅(#!) 실행 이름을 지정합니다. %p - --standalone: Make a bundle that can work without the Bundler runtime + --standalone: 번들러 런타임 없이 실행되는 번들을 만듭니다. %p - --system: Install to the system location ($BUNDLE_PATH or $GEM_HOME) even if the bundle was previously installed somewhere else for this application + --system: 시스템($BUNDLE_PATH 나 $GEM_HOME)에 설치합니다. + 이전에 이 애플리케이션의 번들이 어디에 설치되었든지 관계없습니다. %p - --trust-policy: Sets level of security when dealing with signed gems. Accepts `LowSecurity`, `MediumSecurity` and `HighSecurity` as values. + --trust-policy: 인증된 gem을 다루기 위한 보안 수준을 설정합니다. 값으로 `LowSecurity`, `MediumSecurity`, `HighSecurity`를 사용할 수 있습니다. %p - --without: Exclude gems that are part of the specified named group. + --without: 지정한 그룹의 gem을 제외합니다. .notes %p - Gems will be installed to your default system location for gems. If your - system gems are stored in a root-owned location (such as in Mac OSX), - bundle will ask for your root password to install them there. + gem은 기본 시스템에 설치될 것입니다. 시스템 gem이 루트 권한의 장소(맥 OSX처럼)에 + 설치 된다면 번들은 설치를 위해 관리자 비밀번호를 물어볼 것입니다. %p - While installing gems, Bundler will check vendor/cache and then - your system's gems. If a gem isn't cached or installed, Bundler will try to - install it from the sources you have declared in your Gemfile. + gem을 설치할 동안, 번들러는 vendor/cache와 시스템 gem을 체크합니다. gem이 + 캐시되거나 설치되지 않았다면, 번들러는 Gemfile에서 선언한 소스에서 설치할 것입니다. %p - The --system option is the default. Pass it to switch back after - using the --path option as described below. + --system 옵션은 기본 값입니다. 아래에 설명된 대로 --path 옵션을 + 사용한 이후에 기본 값으로 되돌리고 싶을 때 넘기세요. .bullet#path .description - Install your dependencies, even gems that are already installed - to your system gems, to a location other than your system's gem - repository. In this case, install them to vendor/bundle. + 이미 시스템 gem에 설치되어 있어도 시스템 gem의 저장소가 아닌 곳에 의존성을 설치합니다. + 이 경우에는, vendor/bundle에 설치합니다. .how :code $ bundle install --path vendor/bundle .notes - Further bundle commands or calls to Bundler.setup or - Bundler.require will remember this location. - = link_to 'Learn More: Bundler.setup', './bundler_setup.html' - = link_to 'Learn More: Bundler.require', './groups.html' + 또한 bundle 명령어, Bundler.setup, Bundler.require를 + 위해 이 위치를 기억해둡니다. + = link_to '자세한 내용은: Bundler.setup', './bundler_setup.html' + = link_to '자세한 내용은: Bundler.require', './groups.html' .bullet#without .description - Install all dependencies except those in groups that are explicitly excluded. + 명시적으로 제외한 그룹 외의 모든 의존성을 설치합니다. :code $ bundle install --without development test - = link_to 'Learn More: Groups', './groups.html' + = link_to '자세한 내용은: 그룹', './groups.html' .bullet#deployment .description - Install all dependencies onto a production or CI server. - Do not use this flag on a development machine. + 프로덕션이나 CI 서버에 모든 의존성을 설치합니다. + 개발 기기에서 이 플래그를 사용하지 마세요. :code $ bundle install --deployment .notes %p - The --deployment flag activates a number of deployment- and - CI-friendly conventions: + --deployment 플래그는 여러 가지의 배포나 CI에 친화적인 규칙을 활성화시킵니다. %ul %li - Isolate all gems into vendor/bundle - (equivalent to --path vendor/bundle) + 모든 gem을 vendor/bundle에 격리합니다.(--path vendor/bundle과 같음) %li - Require an up-to-date Gemfile.lock - (equivalent to --frozen) - %li Disable ANSI color output + 최신 Gemfile.lock을 필요로 합니다.(--frozen과 같음) + %li ANSI 색상 출력을 비활성화 합니다. %li - If bundle package was run, do not fetch gems - from rubygems.org. Instead, only use gems in the checked - in vendor/cache - = link_to 'Learn More: Deploying', './deploying.html' + bundle package가 실행되었다면, rubygems.org에서 가져오지 않고, + vendor/cache 안의 gem만 사용합니다. + = link_to '자세한 내용은: 배포하기', './deploying.html' .bullet#jobs .description - Install gems parallely by starting the number of workers specificed. + 지정한 수의 워커를 사용하여 동시에 여러 개의 gem을 설치합니다. :code $ bundle install --jobs 4 .bullet#retry .description - Retry failed network or git requests. + 실패한 네트워크, git 요청을 재시도합니다. :code $ bundle install --retry 3 diff --git a/source/v1.11/bundle_open.haml b/source/v1.11/bundle_open.haml index bcdcc0b01e..b04a12e144 100644 --- a/source/v1.11/bundle_open.haml +++ b/source/v1.11/bundle_open.haml @@ -3,10 +3,10 @@ .contents .bullet .description - Opens the source directory of the given bundled gem + 주어진 번들된 gem의 소스 디렉터리를 엽니다. :code $ bundle open GEM .description %p - Opens the source directory of the provided GEM in your editor. For this to - work the `EDITOR` or `BUNDLER_EDITOR` environment variable has to be set. + 편집기에서 주어진 GEM의 소스 디렉터리를 엽니다. 동작하게 하기 위해서는 + `EDITOR`나 `BUNDLER_EDITOR` 환경변수를 설정할 필요가 있습니다. diff --git a/source/v1.11/bundle_outdated.haml b/source/v1.11/bundle_outdated.haml index ccfd040f56..b81f86c05b 100644 --- a/source/v1.11/bundle_outdated.haml +++ b/source/v1.11/bundle_outdated.haml @@ -3,21 +3,21 @@ .contents .bullet .description - List installed gems with newer versions available + 새로운 버전으로 업데이트 가능한 설치된 gem을 나열합니다. :code $ bundle outdated [GEM] [--local] [--pre] [--source] [--strict] .notes %p - Options: + 옵션: %p - --local: Do not attempt to fetch gems remotely and use the gem cache instead + --local: 원격으로 gem을 가져오지 않고 gem 캐시를 사용합니다. %p - --pre: Check for newer pre-release gems + --pre: 새로운 사전 릴리스 gem을 확인합니다. %p - --source: Check against a specific source + --source: 특정 소스에 대하여 확인합니다. %p - --strict: Display outdated gems that match the dependency requirements. + --strict: 의존성을 만족하는 오래된 gem을 표시합니다. .description - Outdated lists the names and versions of gems that have a newer version available - in the given source. Calling outdated with [GEM [GEM]] will only check for newer - versions of the given gems. By default, available prerelease gems will be ignored. + outdated는 특정 소스에서 새로운 버전이 설치 가능한 gem의 이름과 버전을 나열합니다. + [GEM [GEM]]과 함께 outdated를 부르면 주어진 gem에 대해서만 새로운 버전을 확인합니다. + 설치 가능한 사전 릴리스 gem은 기본적으로 무시됩니다. diff --git a/source/v1.11/bundle_package.haml b/source/v1.11/bundle_package.haml index bf0d402b50..eb35d43a47 100644 --- a/source/v1.11/bundle_package.haml +++ b/source/v1.11/bundle_package.haml @@ -3,38 +3,45 @@ .contents .bullet .description - Locks and then caches the gems into ./vendor/cache. + gem을 ./vendor/cache에 고정하고 캐시합니다. :code $ bundle package [--all] [--all-platforms] [--gemfile=GEMFILE] [--no-prune] [--path=PATH] [--quiet] .notes %p - Options: + 옵션: %p - --all: package :git, :path, and .gem dependencies. Once used, the --all option will be remembered. + --all: :git, :path, + .gem 의존성을 패키징합니다. 한 번 사용되면 --all + 옵션을 기억합니다. %p - --all-platforms: package dependencies for all known platforms, not only the one that bundle package is run on. This option will be remembered in your local Bundler configuration. + --all-platforms: bundle package가 실행 되는 + 환경 뿐만 아니라 모든 알려진 플랫폼을 대상으로 의존성을 패키징합니다. + 이 옵션은 로컬 번들러 설정에 기억됩니다. %p - --gemfile: Use the specified gemfile instead of Gemfile. + --gemfile: Gemfile 대신 지정한 gemfile을 사용합니다. %p - --no-install: Don't actually install the gems, just package. + --no-install: gem을 실제로 설치하지 않고, 패키지만 합니다. %p - --no-prune: Don't remove stale gems from the cache. + --no-prune: 오래된 gem을 캐시에서 제거하지 않습니다. %p - --path: Specify a different path than the system default. + --path: 시스템 기본 값 대신 다른 경로를 지정합니다. %p - --quiet: Only output warnings and errors. + --quiet: 경고와 에러만 출력합니다. .description %p - The package command will copy the .gem files for your gems in the - bundle into ./vendor/cache. Afterward, when you run bundle install, Bundler will use the gems in the cache in preference to the ones on rubygems.org. + package 명령어는 번들 안의 gem을 위한 .gem 파일을 + ./vendor/cache에 복사합니다. 그 후 + bundle install을 실행하면 번들러는 rubygems.org보다 높은 + 우선순위로 캐시 안의 gem을 사용합니다. %p - Additionally, if you then check that directory into your source control repository, others who check out your source will be able to install the bundle without having to download any additional gems. + 추가적으로 버전 관리 저장소에 캐시 디렉터리를 체크인하면 다른 사람들이 + 체크아웃할 때 추가적인 gem의 다운로드 없이 설치하게 할 수 있습니다. .bullet .description - Lock and cache gems from RubyGems into ./vendor/cache. + RubyGems의 gem을 ./vendor/cache에 고정하고 캐시합니다. .how :code @@ -42,19 +49,20 @@ .notes %p - By default, if you simply run bundle install after running - bundle package, Bundler will still connect to rubygems.org to check - whether a platform-specific gem exists for any of the gems in vendor/cache. + 기본 값으로 bundle package 후에 bundle + install을 실행하면 번들러는 여전히 rubygems.org에 접속해 + vendor/cache 안의 gem 중 플랫폼 지정 gem이 있는지 확인합니다. %p - This behavior can be avoided by instead running bundle install --local. - Note that this requires you to have the correctly platformed version for all of your gems - already cached. The easiest way to achieve this is to run bundle package - on an identical machine and then check in those vendored gems. + 이 행동은 bundle install --local을 실행함으로써 회피할 수 + 있습니다. 이 명령은 캐시된 모든 gem에 대해 정확한 플랫폼 버전이 필요하니 + 주의하세요. 이 목표를 달성하기 위한 가장 쉬운 방법은 동일한 기기에서 + bundle package를 실행하고 벤더의 gem을 확인하는 것입니다. .bullet#no-prune .description - Lock and cache gems from RubyGems into ./vendor/cache, and don't remove any stale gems from the existing cache. + gem을 ./vendor/cache에 고정, 캐시하고 오래된 gem을 캐시에서 + 제거하지 않습니다. .how :code @@ -62,14 +70,15 @@ .bullet#all .description - Lock and cache all gems into ./vendor/cache, including :git, :path, and .gem dependencies. + :git, :path, .gem 의존성을 포함해 + gem을 ./vendor/cache에 고정하고 캐시합니다. .how :code $ bundle package --all .notes %p - Once used, the --all option will be remembered. + 한 번 사용되면 --all 옵션을 기억합니다. %p - This will be the default on Bundler 2.0. + 이 옵션은 번들러 2.0에서 기본 값이 됩니다. diff --git a/source/v1.11/bundle_platform.haml b/source/v1.11/bundle_platform.haml index f77674bfe9..e6c9b94dec 100644 --- a/source/v1.11/bundle_platform.haml +++ b/source/v1.11/bundle_platform.haml @@ -3,18 +3,19 @@ .contents .bullet .description - Displays platform compatibility information + 플랫폼 호환성 정보를 표시합니다. :code $ bundle platform [--ruby] .notes %p - Options: + 옵션: %p - --ruby: only display ruby related platform information + --ruby: 루비와 관련된 플랫폼 정보만 표시합니다. .bullet .description - When not passed any options, platform will display information from your Gemfile, Gemfile.lock, and Ruby VM about your platform. You'll see output like the following: + 아무런 옵션도 넘기지 않으면 platform은 플랫폼의 Gemfile, Gemfile.lock, + 루비 VM에서 정보를 출력합니다. 다음과 같은 출력을 보실 수 있습니다. :code $ bundle platform Your platform is: x86_64-linux @@ -27,13 +28,13 @@ Your current platform satisfies the Ruby version requirement. .description - When the ruby directive doesn't match the running Ruby VM, it will tell you what part does not. + ruby 지정이 실행되는 루비 VM과 일치하지 않으면 어느 부분이 일치하지 않는지 말해줍니다. :code Your Ruby version is 1.9.3, but your Gemfile specified 1.8.7 .bullet#ruby .description - When using the --ruby flag, it will just display the ruby directive information, so you don't have to parse it from the Gemfile. + --ruby 플래그를 사용하면 Gemfile로부터 파싱하지 않고도 ruby 지정 정보만 표시할 수 있습니다. :code $ bundle platform --ruby ruby 1.9.3 (jruby 1.6.7) diff --git a/source/v1.11/bundle_show.haml b/source/v1.11/bundle_show.haml index 72080427ed..e78a160433 100644 --- a/source/v1.11/bundle_show.haml +++ b/source/v1.11/bundle_show.haml @@ -3,14 +3,14 @@ .contents .bullet .description - Shows all gems that are part of the bundle, or the path to a given gem + 번들에 포함된 모든 gem을 표시하거나 주어진 gem의 경로를 표시합니다. :code $ bundle show [GEM] [--paths] .notes %p - Options: + 옵션: %p - --paths: List the paths of all gems that are required by your Gemfile. + --paths: Gemfile에서 요청한 모든 gem의 경로를 나열합니다. .description - Show lists the names and versions of all gems that are required by your Gemfile. - Calling show with [GEM] will list the exact location of that gem on your machine. + Gemfile에서 요청한 모든 gem의 이름과 버전을 나열하여 줍니다. + [GEM]과 함께 show를 호출하면 기기에서의 gem의 정확한 위치를 나열합니다. diff --git a/source/v1.11/bundle_update.haml b/source/v1.11/bundle_update.haml index c8f0cf7898..802c479b5c 100644 --- a/source/v1.11/bundle_update.haml +++ b/source/v1.11/bundle_update.haml @@ -3,75 +3,72 @@ .contents .bullet .description - Update the current environment + 현재 환경을 갱신합니다. :code - $ bundle update [GEM] [--full-index] [--group=GROUP] [--jobs=NUMBER] [--local] + $ bundle update [GEM] [--full-index] [--group=GROUP] [--jobs=NUMBER] [--local] [--quiet] [--source=SOURCE] .notes %p - Options: + 옵션: %p - --full-index: Use the rubygems modern index instead of - the API endpoint + --full-index: API 엔드포인트 대신 rubygems의 현대적인 색인을 + 사용합니다. %p - --group: Update one or more gem groups + --group: 하나 이상의 gem 그룹을 업데이트 합니다. %p - --jobs: Specify the number of jobs to run in parallel + --jobs: 병렬로 실행할 잡의 수를 지정합니다. %p - --local: Do not attempt to fetch gems remotely and use - the gem cache instead + --local: 리모트에서 gem을 가져오지 않고 로컬 gem 캐시를 사용하게 합니다. %p - --quiet: Only output warnings and errors. + --quiet: 경고와 에러만 출력합니다. %p - --source: Update a specific source (and all gems - associated with it) + --source: 특정 소스(와 관련된 모든 gem을) 갱신합니다. .description %p - Update the gems specified (all gems, if none are specified), ignoring - the previously installed gems specified in the Gemfile.lock. - In general, you should use bundle install to install the - same exact gems and versions across machines. - + Gemfile.lock 안에 기술된 이전에 설치된 gem을 제외하고, + 지정한 gem을 갱신합니다. (지정하지 않았다면 전부 갱신합니다.) + 일반적으로, 기기 간에 정확히 같은 gem을 설치하려면 bundle + install을 사용해야 합니다. + %p - You would use bundle update to explicitly update the - version of a gem. + bundle update는 명시적으로 gem 버전의 갱신이 필요할 때만 + 사용합시다. .bullet .description - Update the current environment. + 현재 환경을 갱신합니다. .how :code $ bundle update .notes - If you run bundle update with no parameters, bundler will - ignore any previously installed gems and resolve all dependencies again - based on the latest versions of all gems available in the sources. + 매개변수 없이 bundle update를 실행하면, 번들러는 전에 설치한 + gem을 점부 무시하고 모든 의존성을 소스 서버의 최신 버전을 기준으로 다시 해결합니다. .bullet#source .description - Update a specific source (and all gems associated with it) + 지정한 소스로부터 gem(과 관련된 모든 gem)을 갱신합니다. .how :code $ bundle update --source=SOURCE .notes - The name of a :git or :path source used in the - Gemfile. For instance, with a :git source of - http://github.com/rails/rails.git, you would call - bundle update --source rails. + Gemfile 안에서 사용된 :git이나 :path + 소스가 사용된 gem의 이름입니다. 예를 들어, :git 소스 + http://github.com/rails/rails.git의 경우, + bundle update --source rails를 불러야 합니다. %h2 Update all gems .contents .bullet#update_all_extended .description %p - If you run bundle update with no parameters, bundler will - ignore any previously installed gems and resolve all dependencies again - based on the latest versions of all gems available in the sources. + 매개변수 없이 bundle update를 실행했다면, 번들러는 모든 + 이전에 설치된 gem을 무시하고 소스 안의 모든 gem의 가능한 최신 버전을 + 기반으로 모든 의존성을 다시 해결하려 합니다. %p - Consider the following Gemfile: + 다음과 같은 Gemfile이 있다고 해봅시다. :code # lang: ruby @@ -79,9 +76,8 @@ gem 'rails', '3.0.0.rc' gem 'nokogiri' %p - When you run bundle install the first time, bundler will - resolve all of the dependencies, all the way down, and install what you - need: + 처음 bundle install을 실행할 때, 번들러는 필요한 모든 + 의존성을 해결한 다음 설치할 것입니다. :code Fetching source index for https://rubygems.org/ Installing rake (0.8.7) @@ -113,62 +109,57 @@ Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. %p - As you can see, even though you have just two gems in the - Gemfile, your application actually needs 25 different gems - in order to run. Bundler remembers the exact versions it installed in - Gemfile.lock. The next time you run - bundle install, bundler skips the dependency resolution and - installs the same gems as it installed last time. + 보시다시피, Gemfile 안에 두 개의 gem만 있다고 해도, 실제 + 애플리케이션을 실행하려면 25개의 다른 gem이 필요합니다. 번들러는 + 설치된 gem의 정확한 버전을 Gemfile.lock 안에 기억해둡니다. + 다음에 bundle install을 실행할 때에는, 번들러는 마지막으로 + 설치 됐던 모든 gem의 의존성 해결과 설치를 생략합니다. %p - After checking in the Gemfile.lock into version control and - cloning it on another machine, running bundle install will - _still_ install the gems that you installed last time. You don't need to - worry that a new release of erubis or mail - changes the gems you use. + Gemfile.lock을 버전 관리 시스템에 추가하고 다른 기기에서 클론한 후에 + bundle install을 실행하면 _여전히_ 마지막에 설치했던 gem을 + 설치합니다. erubis, mail의 새 버전이 나왔는지 + 걱정할 필요가 없어요. %p - However, from time to time, you might want to update the gems you are - using to the newest versions that still match the gems in your - Gemfile. + 하지만 때때로 Gemfile의 정보와 일치하는 최신 버전으로 + 갱신해야 할 때가 있습니다. %p - To do this, run bundle update, which will ignore the - Gemfile.lock, and resolve all the dependencies again. Keep - in mind that this process can result in a significantly different set - of the 25 gems, based on the requirements of new gems that the gem - authors released since the last time you ran bundle update. + 이럴 때엔 bundle update를 실행하시면 Gemfile.lock을 + 무시하고 모든 의존성을 다시 해결합니다. 이 과정은 마지막으로 + bundle update를 실행한 이후 gem의 저자들이 새로 릴리스한 gem을 + 기반으로 새로운 gem을 요청하므로 25개의 gem 모두 현저히 달라질 수 있으므로 + 주의하세요. %h2 Update a list of gems. .contents .bullet#update_list_of_gems .description %p - Sometimes, you want to update a single gem in the Gemfile, - and leave the rest of the gems that you specified locked to the - versions in the Gemfile.lock. + 가끔 Gemfile 안의 나머지 gem은 Gemfile.lock 안의 + 버전으로 고정하고 하나의 gem만 갱신해야 할 때가 있습니다. %p - For instance, in the scenario above, imagine that - nokogiri releases version 1.4.4, and you want - to update it _without_ updating Rails and all of its dependencies. To - do this, run + 예를 들어 위의 시나리오에서 nokogiri의 릴리스 버전이 + 1.4.4이고 레일스와 모든 의존성의 _갱신 없이_ nokogiri만 + 릴리스 해야 할 경우, 다음과 같이 하면 됩니다. :code bundle update nokogiri %p - Bundler will update nokogiri and any of its dependencies, - but leave alone Rails and its dependencies. + 번들러는 nokogiri와 그 의존성만 갱신하고, 레일스나 그 의존성은 + 그냥 둘 것입니다. %h2 Overlapping dependencies .contents .bullet#overlapping_dependencies .description %p - Sometimes, multiple gems declared in your Gemfile are - satisfied by the same second-level dependency. For instance, consider the - case of thin and rack-perftools-profiler. + 가끔 Gemfile 안에 여러 gem이 같은 하위(second-level) 의존성을 + 만족할 수 있습니다. 예를 들어 thin과 + rack-perftools-profiler가 있다고 해보죠. :code # lang: ruby @@ -178,9 +169,9 @@ gem 'rack-perftools-profiler' %p - The thin gem depends on rack >= 1.0, while - rack-perftools-profiler depends on rack ~> 1.0. - If you run bundle install, you get: + thin gem은 rack >= 1.0에 의존합니다. 한편 + rack-perftools-profiler는 rack ~> 1.0에 의존 + 합니다. 번들을 설치하면 다음 결과를 얻게 됩니다. :code Fetching source index for https://rubygems.org/ @@ -194,25 +185,23 @@ Using bundler (1.0.0.rc.3) %p - In this case, the two gems have their own set of dependencies, but they - share rack in common. If you run bundle update - thin, bundler will update daemons, - eventmachine and rack, which are dependencies - of thin, but not open4 or - perftools.rb, which are dependencies of - rack-perftools_profiler. Note that - bundle update thin will update rack even though - it's _also_ a dependency of rack-perftools_profiler. + 이 경우 두 gem이 각각의 의존성을 가지고 있지만, 공통으로 rack을 + 공유하고 있습니다. bundle update thin을 실행하면 번들은 + thin에 의존하는 daemons, + eventmachine, rack을 갱신하지만 + rack-perftools_profiler에 의존하는 open4, + perftools.rb는 갱신하지 않습니다. + bundle update thin은 rack-perftools_profiler_에도_ + 의존성이 있음에도 불구하고 rack을 갱신함에 주의하세요. %p - In short, when you update a gem using - bundle update, bundler will update all dependencies of that - gem, including those that are also dependencies of another gem. + 요약하면 bundle update를 이용해 gem을 갱신할 때는 번들러는 + 다른 gem에 의존하는 gem도 포함해 그 gem의 모든 의존성도 같이 갱신합니다. %p - In this scenario, updating the thin version manually in the - Gemfile, and then running bundle install will - only update daemons and eventmachine, but not - rack. + 이 시나리오에서 Gemfile에서 thin의 버전을 + 수동으로 갱신하고 bundle install을 실행하면 + daemons와 eventmachine을 갱신하지만 + rack은 갱신하지 않습니다. -# For more information, see the CONSERVATIVE UPDATING -#section of bundle install. diff --git a/source/v1.11/bundle_version.haml b/source/v1.11/bundle_version.haml index 54c1e71dc1..c757f30834 100644 --- a/source/v1.11/bundle_version.haml +++ b/source/v1.11/bundle_version.haml @@ -3,6 +3,6 @@ .contents .bullet .description - Prints the bundler's version information + 번들러의 버전 정보를 출력합니다. :code $ bundle version diff --git a/source/v1.11/bundle_viz.haml b/source/v1.11/bundle_viz.haml index f7b4cafb26..23c7a73e93 100644 --- a/source/v1.11/bundle_viz.haml +++ b/source/v1.11/bundle_viz.haml @@ -3,25 +3,25 @@ .contents .bullet .description - Generates a visual dependency graph + 비주얼 의존성 그래프를 생성합니다. :code $ bundle viz [--file=FILE] [--format=FORMAT] [--requirements] [--version] [--without=GROUP GROUP] .notes %p - Options: + 옵션: %p - --file or -f: The name to use for the generated file. see format option + --file or -f: 만들어질 파일의 이름. format 옵션 참조 %p - --format or -F: This is output format option. Supported format is png, jpg, svg, dot ... + --format or -F: 아웃풋 포맷 옵션. 지원되는 포맷은 png, jpg, svg, dot ... %p - --requirements or -r: Set to show the version of each required dependency. + --requirements or -r: 각 요구된 의존성의 버전을 표시하도록 설정. %p - --version or -v: Set to show each gem version. + --version or -v: 각 gem의 버전을 표시하도록 설정. %p - --without: Exclude gems that are part of the specified named group. - = link_to 'Learn More: Groups', './groups.html' + --without: 특정 이름의 그룹의 일부인 gem을 제외 + = link_to '자세한 내용은: 그룹', './groups.html' .description - Viz generates a PNG file of the current Gemfile as a dependency graph. - Viz requires the ruby-graphviz gem (and its dependencies). - The associated gems must also be installed via 'bundle install'. + Viz는 현재 Gemfile의 의존성 그래프를 PNG 파일로 생성합니다. + Viz는 ruby-graphviz gem(과 그 의존성들)이 요구됩니다. + 관련 gem은 'bundle install'을 통해서도 설치되어야 합니다. diff --git a/source/v1.11/bundler_setup.haml b/source/v1.11/bundler_setup.haml index 82276cb26f..b2552746f2 100644 --- a/source/v1.11/bundler_setup.haml +++ b/source/v1.11/bundler_setup.haml @@ -3,8 +3,8 @@ .contents .bullet .description - Configure the load path so all dependencies in - your Gemfile can be required + 로드 경로를 설정해 Gemfile의 모든 의존성을 + require할 수 있게 하기 :code # lang: ruby require 'rubygems' @@ -13,41 +13,40 @@ .bullet .description - Only add gems from specified groups to the - load path. If you want the gems in the - default group, make sure to include it + 로드 경로에 특정 그룹의 gem만을 추가합니다. + 기본 그룹의 gem도 넣고 싶다면, 포함시킬 필요가 + 있습니다. :code # lang: ruby require 'rubygems' require 'bundler' Bundler.setup(:default, :ci) require 'nokogiri' - = link_to 'Learn More: Groups', './groups.html' + = link_to '자세한 내용은: 그룹', './groups.html' -%h2 Compatibility +%h2 호환성 .contents .bullet .description - Ruby 2.0 and RubyGems 2.0 both require Bundler 1.3 or later. If you have questions about compatibility between Bundler and your system, please check the compatibility list. - = link_to 'Learn More: Compatibility', '/compatibility.html' + 루비 2.0과 RubyGems 2.0 둘 다 번들러 1.3 이후의 버전이 필요합니다. 번들러와 시스템의 호환성이 궁금하시다면, 호환성 목록을 확인하세요. + = link_to '자세한 내용은: 호환성', '/compatibility.html' %h2#setting-up-your-application-to-use-bundler - Setting Up Your Application to Use Bundler + 번들러를 사용해 애플리케이션 설정하기 .bullet .description - Bundler makes sure that Ruby can find all of the gems in the Gemfile - (and all of their dependencies). If your app is a Rails 3 app, your default application - already has the code necessary to invoke bundler. If it is a Rails 2.3 app, please see: - Setting up Bundler in Rails 2.3 + 번들러는 루비가 Gemfile 안의 모든 gem(과 거기에 의존하는 모든 gem)을 찾을 + 수 있는지 확인합니다. 애플리케이션이 레일스 3 애플리케이션이라면 번들러를 호출하기 위한 + 코드가 기본으로 포함되어 있습니다. 레일스 2.3 애플리케이션이라면 다음 링크를 확인하세요. + 번들러를 레일스 2.3과 사용하기 .bullet .description - For another kind of application (such as a Sinatra application), you will need to set up - bundler before trying to require any gems. At the top of the first file that your - application loads (for Sinatra, the file that calls require 'sinatra'), put - the following code: + 시나트라 같은 다른 종류의 애플리케이션에선 gem을 require하기 전에 번들러를 설정할 필요가 + 있습니다. 애플리케이션에서 처음 로드되는 파일(시나트라에서는 require + 'sinatra'를 호출하는 파일)의 제일 윗부분에 다음 코드를 넣으세요. :code # lang: ruby @@ -56,23 +55,22 @@ .bullet .description - This will automatically discover your Gemfile, and make all of the gems in - your Gemfile available to Ruby (in technical terms, it puts the gems "on the - load path"). You can think of it as an adding some extra powers to require - 'rubygems'. + 이렇게 하면 Gemfile을 찾아, Gemfile의 모든 gem을 루비에서 + 사용가능하게 만들어 줍니다.(기술적인 관점에서 보면 로드 경로에 gem을 넣어 줍니다.) + require 'rubygems'에 추가적인 기능을 부여한다고 생각하셔도 됩니다. .bullet .description - Now that your code is available to Ruby, you can require the gems that you need. For - instance, you can require 'sinatra'. If you have a lot of dependencies, you - might want to say "require all of the gems in my Gemfile". To do this, put - the following code immediately following require 'bundler/setup': + 이제 코드가 루비에서 사용가능하므로, 필요한 gem을 require 할 수 있습니다. 예를 들어 + require 'sinatra'를 할 수 있습니다. 많은 의존성을 가지고 있다면 + "Gemfile 안의 모든 의존성을 require"하고 싶을 수도 있습니다. 이렇게 하려면 + require 'bundler/setup'을 넣으시면 됩니다. :code # lang: ruby Bundler.require(:default) - For our example Gemfile, this line is exactly equivalent to: + 예제 Gemfile대로라면, 이 라인은 다음 코드들을 실행한 것과 동일한 결과를 얻습니다. :code # lang: ruby @@ -82,9 +80,10 @@ .bullet .description - Astute readers will notice that the correct way to require the rack-cache - gem is require 'rack/cache', not require 'rack-cache'. To tell - bundler to use require 'rack/cache', update your Gemfile: + 눈치 빠른 분들은 rack-cache gem을 require하는 바른 방법은 require + 'rack-cache'가 아니라 require 'rack/cache'인 것을 눈치채셨을 + 것입니다. 번들러가 require 'rack/cache'를 사용하도록 하려면 Gemfile을 + 고치세요. :code # lang: ruby @@ -96,8 +95,7 @@ .bullet .description - For such a small Gemfile, we'd advise you to skip - Bundler.require and just require the gems by hand (especially given the - need to put in a :require directive in the Gemfile). For much - larger Gemfiles, using Bundler.require allows you to skip - repeating a large stack of requirements. + 작은 Gemfile은 Bundler.require를 사용하지 않고 직접 require + 하는 걸 추천합니다.(Gemfile 안에 :require를 넣어야 한다면 더더욱) + 큰 Gemfile은 Bundler.require해서 많은 요구사항을 반복적으로 + 입력하지 않을 수 있습니다. diff --git a/source/v1.11/bundler_sharing.haml b/source/v1.11/bundler_sharing.haml index 8734945302..6c9d2062a0 100644 --- a/source/v1.11/bundler_sharing.haml +++ b/source/v1.11/bundler_sharing.haml @@ -1,60 +1,55 @@ %h2#sharing - Sharing + 공유하기 .contents .bullet .description %h3#checking-your-code-into-version-control - Checking Your Code into Version Control + 코드를 버전 관리하기 %p - After developing your application for a while, check in the application together with the - Gemfile and Gemfile.lock snapshot. Now, your repository has a - record of the exact versions of all of the gems that you used the last time you know for - sure that the application worked. Keep in mind that while your Gemfile - lists only three gems (with varying degrees of version strictness), your application - depends on dozens of gems, once you take into consideration all of the implicit - requirements of the gems you depend on. + 한동안 애플리케이션을 개발한 다음 애플리케이션을 Gemfile, + Gemfile.lock과 함께 체크인하세요. 이때 저장소는 마지막으로 애플리케이션이 + 동작했을 때 사용한 gem의 정확한 버전의 기록을 가지고 있습니다. + Gemfile에(버전의 엄격함의 정도에 차이도 있겠지만) + 3개의 gem만 있다고 하더라도 애플리케이션은 수십 개의 gem을 의존하고 의존하는 + 모든 암시적인 gem의 요구사항을 고려해야 합니다. %p.description - This is important: the Gemfile.lock makes your application a single - package of both your own code and the third-party code it ran the last time you know for - sure that everything worked. Specifying exact versions of the third-party code - you depend on in your Gemfile would not provide the same guarantee, because - gems usually declare a range of versions for their dependencies. + Gemfile.lock이 애플리케이션의 코드와 gem이 제대로 동작했다는 + 확신이 있는 최후의 순간을 하나의 묶음으로 만든다는 점은 중요합니다. + Gemfile에 gem의 정확한 버전을 지정한다 하여도 같은 수준의 보장은 안 됩니다. + 왜냐하면 gem은 보통 의존성을 범위로 지정하기 때문입니다. %p.description - The next time you run bundle install on the same machine, bundler will see - that it already has all of the dependencies you need, and skip the installation process. + 이후 같은 기기에서 bundle install을 실행하면, 모든 필요한 의존성을 만족하므로 + 번들러가 설치 과정을 생략하는 것을 볼 수 있습니다. %p.description - Do not check in the .bundle directory, or any of the files inside it. Those - files are specific to each particular machine, and are used to persist installation options - between runs of the bundle install command. + .bundle 디렉터리와 그 안의 어떤 내용도 체크인하지 말아 주세요. 그 파일들을 + 각각의 기기의 특성에 따라 달라지고 bundle install 명령어 간의 영속적인 설치 + 옵션을 사용합니다. %p.description - If you have run bundle pack, the gems (although not the git gems) required - by your bundle will be downloaded into vendor/cache. Bundler can run without - connecting to the internet (or the RubyGems server) if all the gems you need are present - in that folder and checked in to your source control. This is an optional - step, and not recommended, due to the increase in size of your source control repository. + bundle pack 명령어를 실행했고 git의 gem이 아니라면, 번들러에서 요구된 gem은 + 모두 vendor/cache에 다운로드 됩니다. 모든 필요한 gem이 폴더에 들어있고 + 버전 관리에 체크인 되어있다면 인터넷이나 루비젬스 서버에 접속하지 않고 실행할 수 있습니다. + 이것은 생략가능한 과정이며, 버전 관리 저장소의 크기를 늘리므로 추천하지 + 않습니다. .bullet %h3#sharing-your-application-with-other-developers - Sharing Your Application With Other Developers + 애플리케이션을 다른 개발자와 공유하기 %p.description - When your co-developers (or you on another machine) check out your code, it will come - with the exact versions of all the third-party code your application used on the machine - that you last developed on (in the Gemfile.lock). When **they** run - bundle install, bundler will find the Gemfile.lock and skip - the dependency resolution step. Instead, it will install all of the same gems that you - used on the original machine. + 동료 개발자가 코드를 채크아웃하거나 당신이 다른 기기에 체크아웃하면 개발할 때 애플리케이션에서 + 사용했던 모든 gem의 정확한 버전도(Gemfile.lock 안에) 함께 옵니다. + **거기서** bundle install을 실행하면 번들러는 Gemfile.lock을 찾고 + 의존성 해결과정을 생략합니다. 대신에 원래 기기에서 사용했던 것과 같은 모든 gem을 설치합니다. %p.description - In other words, you don't have to guess which versions of the dependencies you should - install. In the example we've been using, even though rack-cache declares a - dependency on rack >= 0.4, we know for sure it works with rack - 1.2.1. Even if the Rack team releases rack 1.2.2, bundler will - always install 1.2.1, the exact version of the gem that we know works. This - relieves a large maintenance burden from application developers, because all machines - always run the exact same third-party code. + 다시 말하자면 어떤 버전의 의존성을 설치해야 하는지 고민할 필요가 없습니다. 아까 보았던 + 예제에서 rack-cache가 rack >= 0.4에 의존성이 있다고 정의되어도 + rack 1.2.1에서 움직인다고 확신할 수 있습니다. Rack 팀이 rack 1.2.2를 + 릴리스하더라도 번들러는 항상 동작이 보장되는 1.2.1을 설치합니다. 이것은 + 개발자로 하여금 많은 관리부담을 덜게 합니다. 왜냐하면, 모든 기기에서 똑같은 gem을 사용하기 + 때문입니다. diff --git a/source/v1.11/bundler_workflow.haml b/source/v1.11/bundler_workflow.haml index b05de90b5d..3abb798501 100644 --- a/source/v1.11/bundler_workflow.haml +++ b/source/v1.11/bundler_workflow.haml @@ -1,71 +1,69 @@ -%h2 Recommended Workflow with Version Control +%h2 버전 관리의 추천 워크플로우 .contents .bullet#recommended_workflow .description %p - In general, when working with an application managed with bundler, you - should use the following workflow: + 일반적으로, 번들러로 관리된 애플리케이션으로 일할 때에는 이하의 + 워크플로우를 사용하는 게 바람직합니다. %p - After you create your Gemfile for the first time, run + 처음 Gemfile을 생성한 다음에 다음 명령어를 실행합니다. :code $ bundle install %p - Check the resulting Gemfile.lock into version control + 결과로 나온 Gemfile.lock을 버전 관리합니다. :code $ git add Gemfile.lock %p - When checking out this repository on another development machine, run + 이 저장소를 다른 기기에서 체크아웃할 때엔 다음 명령어를 실행합니다. :code $ bundle install %p - When checking out this repository on a deployment machine, run + 이 저장소를 배포 기기에 체크아웃할 때엔 다음 명령어를 실행합니다. :code $ bundle install --deployment %p - After changing the Gemfile to reflect a new or update - dependency, run + Gemfile을 변경한 후에, 새로운 의존성이나 갱신된 의존성을 + 반영하기 위해서는 다음 명령어를 실행합니다. :code $ bundle install %p - Make sure to check the updated Gemfile.lock into version - control + 갱신된 Gemfile.lock이 버전 관리되는지 확인합니다. :code $ git add Gemfile.lock %p - If bundle install reports a conflict, manually update the - specific gems that you changed in the Gemfile + bundle install이 충돌을 보고하면, Gemfile + 에서 변경한 특정 gem을 수동으로 갱신해야 합니다. :code $ bundle update rails thin %p - If you want to update all the gems to the latest possible versions that - still match the gems listed in the Gemfile, run + Gemfile 안에 있는 gem의 조건을 만족하면서 가능한 최신 버전으로 + 갱신하려면, 다음 명령어를 실행합니다. :code $ bundle update -%h2 A Thorough Bundler Workflow +%h2 번들러 워크플로우 철저하게 살펴보기 .contents .bullet .description - Getting started with bundler is easy! Open a terminal window and run this command: + 번들러는 시작하기 쉽습니다! 터미널 윈도우를 열고 이 명령어를 실행합니다. :code $ gem install bundler .notes %li - When you first create a Rails application, it already comes with a - Gemfile. For another kind of application (such as Sinatra), run: + 처음 레일스 애플리케이션을 생성했을 때부터 Gemfile이 이미 포함되어 있습니다. + (시나트라 같은) 다른 종류의 애플리케이션은 이 명령어를 실행합니다. :code $ bundle init %li - The bundle init command creates a simple Gemfile which you - can edit. + bundle init 명령어는 수정할 수 있는 간단한 Gemfile을 생성합니다. .bullet .description - Specify your dependencies in the root of your application, called the Gemfile. - It looks something like this: + Gemfile은 애플리케이션 루트에 의존성을 특정한 것입니다. + 이런 내용들이 들어있습니다. :code # lang: ruby source 'https://rubygems.org' @@ -74,24 +72,24 @@ gem 'rspec', :require => 'spec' .notes - This Gemfile says a few things. First, it says that bundler should - look for gems declared in the Gemfile at https://rubygems.org by default. - = link_to 'Learn More: Gemfiles', './gemfile.html' + 이 Gemfile은 여러 가지를 말해줍니다. 첫째, 번들러는 + Gemfile 안에 선언된 gem을 기본 값인 + https://rubygems.org 안에서 찾을 것입니다. + = link_to '자세한 내용은: Gemfile', './gemfile.html' .bullet .description %p - After declaring your first set of dependencies, you tell bundler to go get them: + 첫 의존성을 선언한 이후, 번들러에게 받도록 해야합니다. :code - $ bundle install # bundle is a shortcut for bundle install + $ bundle install # bundle은 bundle install의 단축입니다. %p - Bundler will connect to rubygems.org (and any other sources that you declared), - and find a list of all of the required gems that meet the requirements you specified. - Because all of the gems in your Gemfile have dependencies of their own - (and some of those have their own dependencies), running bundle install on the - Gemfile above will install quite a few gems. + 번들러는 rubygems.org(아니면 다른 선언된 소스)에 접속해, 모든 필요한 gem의 + 목록(지정한 요구사항을 충족하는 gem 목록)을 찾습니다. Gemfile 안의 모든 gem은 + 각자 의존성을 가지고 있고 또 그 의존성의 일부는 각자의 의존성을 가지고 있기 때문에, + bundle install을 실행하면 위의 Gemfile로도 꽤 많은 gem이 설치됩니다. :code $ bundle install @@ -126,44 +124,42 @@ Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. %p - If any of the needed gems are already installed, Bundler will use them. After installing - any needed gems to your system, bundler writes a snapshot of all of the gems and - versions that it installed to Gemfile.lock. + 필요한 gem 중 일부가 이미 설치되어 있다면, 번들러는 그것을 사용합니다. 시스템에서 필요한 + gem을 모두 설치한 후, 번들러는 Gemfile.lock에 설치된 모든 gem과 버전 + 정보의 스냅숏을 기록합니다. .notes %li - If bundle install reports a conflict between your Gemfile and - Gemfile.lock, run: + bundle install이 Gemfile과 Gemfile.lock 사이에 + 충돌을 보고한다면 다음 명령을 실행합니다. :code $ bundle update sinatra %li - This will update just the Sinatra gem, as well as any of its dependencies. + 이 명령어는 Sinatra gem뿐만 아니라 시나트라의 모든 의존성을 갱신합니다. %p %li - To update all of the gems in your Gemfile to the latest possible versions, run: + Gemfile 안의 모든 가능한 최신 버전을 갱신하려면, 다음을 실행합니다. :code $ bundle update %li - Whenever your Gemfile.lock changes, always check it in to version control. - It keeps a history of the exact versions of all third-party code that you used to successfully - run your application. + Gemfile.lock이 변경되었다면, 반드시 버전 관리에 넣도록 합니다. + 이렇게 하면, 성공적으로 애플리케이션이 동작했을 때의 모든 서드파티 코드의 정확한 버전 이력이 남습니다. %li - The git add Gemfile* command adds the Gemfile and Gemfile.lock to your repository. This ensures that - other developers on your app, as well as your deployment environment, will all use the same - third-party code that you are using now. + git add Gemfile* 명령어는 Gemfile과 Gemfile.lock 파일을 저장소에 추가합니다. 이렇게 하면 + 애플리케이션의 다른 개발자가 당신의 개발 환경과 같은 서드 파티 코드를 사용하도록 할 수 있습니다. .buttons - = link_to 'Learn More: bundle install', './bundle_install.html' - = link_to 'Learn More: bundle update', './bundle_update.html' + = link_to '자세한 내용은: bundle install', './bundle_install.html' + = link_to '자세한 내용은: bundle update', './bundle_update.html' .bullet .description - Inside your app, load up the bundled environment: + 애플리케이션 안에서 번들된 환경을 로드합니다. :code # lang: ruby require 'rubygems' @@ -171,28 +167,28 @@ # require your gems as usual require 'nokogiri' - = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + = link_to '자세한 내용은: Bundler.setup', './bundler_setup.html' .bullet .description - Run an executable that comes with a gem in your bundle: + 번들 안의 gem과 같이 오는 실행 파일을 실행합니다. :code $ bundle exec rspec spec/models .notes %p - In some cases, running executables without bundle exec - may work, if the executable happens to be installed in your system - and does not pull in any gems that conflict with your bundle. + 어떤 경우에는, bundle exec 없이 실행 파일이 실행 될 수 + 있습니다. 시스템에 실행 파일이 설치 되어있고 번들에 있는 어떤 gem과도 + 충돌 하지 않을 때라면요. %p - However, this is unreliable and is the source of considerable pain. - Even if it looks like it works, it may not work in the future or - on another machine. + 하지만 이 상태는 신뢰할 수 없고 나중에 상당한 문제가 될 수 있습니다. + 움직이는 것처럼 보인다고 하더라도, 미래나 다른 기기에서는 움직이지 + 않을 수 있습니다. .bullet .description - Finally, if you want a way to get a shortcut to gems in your bundle: + 마지막으로, 번들 안에 있는 gem의 단축 명령이 필요하다면 이렇게 할 수 있습니다. :code $ bundle install --binstubs $ bin/rspec spec/models .notes - The executables installed into bin are scoped to the - bundle, and will always work. - = link_to 'Learn More: Executables', './man/bundle-exec.1.html' + 이 실행 파일들은 번들의 범위로 bin 안에 설치되며 언제나 + 동작할 것입니다. + = link_to '자세한 내용은: 실행파일', './man/bundle-exec.1.html' diff --git a/source/v1.11/commands.haml b/source/v1.11/commands.haml index e937aae548..ee4fc94c28 100644 --- a/source/v1.11/commands.haml +++ b/source/v1.11/commands.haml @@ -9,53 +9,53 @@ applicable options = command_table_row do |command| - command.name = 'binstubs' - - command.desc = 'Installs the binstubs of the listed gem' + - command.desc = '나열된 gem의 binstubs를 설치' - command.option = 'force' - command.option = 'path' = command_table_row do |command| - command.name = 'check' - - command.desc = 'Checks if the dependencies listed in Gemfile are satisfied by currently installed gems' + - command.desc = 'Gemfile의 목록이 현재 설치된 gem의 의존성을 만족하는지 확인' - command.option = 'dry-run' - command.option = 'gemfile' - command.option = 'path' = command_table_row do |command| - command.name = 'clean' - - command.desc = 'Cleans up unused gems in your bundler directory' + - command.desc = '번들러 디렉터리에서 사용하지 않는 gem을 청소' - command.option = 'dry-run' - command.option = 'force' = command_table_row do |command| - command.name = 'config' - - command.desc = 'Retrieve or set a configuration value' + - command.desc = '설정 값을 보거나 지정' - command.option = 'local' - command.option = 'global' - command.option = 'delete' = command_table_row do |command| - command.name = 'console' - - command.desc = 'Opens an IRB session with the bundle pre-loaded' + - command.desc = '번들이 프리로드된 IRB 세션 열기' = command_table_row do |command| - command.name = 'exec' - - command.desc = 'Run the command in context of the bundle' + - command.desc = '번들의 컨텍스트에서 명령어 실행' - command.option = 'keep-file-descriptors' = command_table_row do |command| - command.name = 'gem' - - command.desc = 'Creates a skeleton for creating a rubygem' + - command.desc = '루비젬을 만들기 위한 뼈대 생성' - command.option = 'bin or -b' - command.option = 'edit' - command.option = 'ext' - command.option = 'test' = command_table_row do |command| - command.name = 'help' - - command.desc = 'Displays detailed help for each subcommand' + - command.desc = '각 하위 명령어의 자세한 도움말 표시' = command_table_row do |command| - command.name = 'init' - - command.desc = 'Generates a Gemfile into the current working directory' + - command.desc = '현재 디렉터리에 Gemfile 생성' - command.option = 'gemspec' = command_table_row do |command| - command.name = 'inject' - - command.desc = 'Add the named gem(s), with version requirements, to the resolved Gemfile' + - command.desc = '결정된 Gemfile에 gem 이름과 버전 추가' = command_table_row do |command| - command.name = 'install' - - command.desc = 'Install the current environment to the system' + - command.desc = '시스템에 현재 환경을 설치' - command.option = 'binstubs' - command.option = 'clean' - command.option = 'deployment' @@ -76,17 +76,17 @@ - command.option = 'without' = command_table_row do |command| - command.name = 'open' - - command.desc = 'Opens the source directory of the given bundled gem' + - command.desc = '주어진 번들 gem의 소스 디렉터리 열기' = command_table_row do |command| - command.name = 'outdated' - - command.desc = 'List installed gems with newer versions available' + - command.desc = '새로운 버전이 나온 설치된 gem 목록' - command.option = 'local' - command.option = 'pre' - command.option = 'source' - command.option = 'strict' = command_table_row do |command| - command.name = 'package' - - command.desc = 'Locks and then caches all of the gems into vendor/cache' + - command.desc = 'vendor/cache에 모든 gem을 캐시, 락' - command.option = 'all' - command.option = 'all-platforms' - command.option = 'gemfile' @@ -96,15 +96,15 @@ - command.option = 'quiet' = command_table_row do |command| - command.name = 'platform' - - command.desc = 'Displays platform compatibility information' + - command.desc = '플랫폼 호환성 정보 표시' - command.option = 'ruby' = command_table_row do |command| - command.name = 'show' - - command.desc = 'Shows all gems that are part of the bundle, or the path to a given gem' + - command.desc = '번들에 포함된 모든 gem의 목록이나, 특정 gem의 경로를 표시' - command.option = 'paths' = command_table_row do |command| - command.name = 'update' - - command.desc = 'Update the current environment' + - command.desc = '현재 환경을 업데이트' - command.option = 'full-index' - command.option = 'group' - command.option = 'jobs' @@ -113,10 +113,10 @@ - command.option = 'source' = command_table_row do |command| - command.name = 'version' - - command.desc = 'Prints version information' + - command.desc = '버전 정보 출력' = command_table_row do |command| - command.name = 'viz' - - command.desc = 'Generates a visual dependency graph' + - command.desc = '비주얼 의존성 그래프 생성' - command.option = 'file or -f' - command.option = 'format or -F' - command.option = 'requirements or -r' diff --git a/source/v1.11/deploying.haml b/source/v1.11/deploying.haml index fc6502db1e..a9eb0bc4da 100644 --- a/source/v1.11/deploying.haml +++ b/source/v1.11/deploying.haml @@ -1,63 +1,61 @@ -%h2 Deploying bundled applications +%h2 번들러를 사용하는 애플리케이션 배포 .contents .bullet .description - 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. + 번들러를 사용하는 앱을 배포하기 전에 Gemfile과 + Gemfile.lock을 버전 관리하세요. 하지만 .bundle은 + 각 기기에 따라 지정되므로 제외하셔야 합니다. :code $ echo ".bundle" >> .gitignore $ git add Gemfile Gemfile.lock .gitignore $ git commit -m "Add Bundler support" .notes - Once you have done that, there are two ways to deploy using Bundler: - manually or automatically. + 하셨다면 수동 또는 자동으로 배포가 가능합니다. .bullet .description - %h3 Manual deployment - In your deploy script, after updating to the latest - code, install your bundle to the vendor/bundle - directory, ensuring all your dependencies are met. + %h3 수동 배포 + 최신 코드로 갱신한 후 배포 스크립트에서 번들을 + vendor/bundle 디렉터리에 설치하고 + 모든 의존성을 만족하는지 확인합니다. :code $ bundle install --deployment .notes %p - Start your application servers as usual, and your - application will use your bundled environment - with the exact same gems you use in development. + 평상시처럼 애플리케이션 서버를 기동하면 개발 환경과 + 완전히 동일한 번들러 환경을 사용합니다. %p - If you have run bundle package, the cached - gems will be used automatically. + bundle package를 실행했다면 자동으로 + 캐시된 gem이 사용됩니다. - = link_to 'Learn More: Packing', './bundle_package.html' + = link_to '자세한 내용은: Packing', './bundle_package.html' .bullet - %h3 Automatic deployment with Capistrano + %h3 카피스트라노로 하는 자동 배포 .description - To pull in the Bundler Cap task, just add this to your - deploy.rb file: + 번들러 카피스트라노 작업에서 풀(pull)하려면 이 코드를 + deploy.rb에 추가하시기만 하면 됩니다. :code # lang: ruby require 'bundler/capistrano' .notes - That's it! Running cap deploy will now automatically run - bundle install on the remote server with deployment-friendly - options. A list of options that can be changed is available in the help - for the cap task. To see it, run cap -e bundle:install. + 끝입니다! 이제 cap deploy를 실행하시면 자동으로 원격 서버에서 + 배포용 옵션과 함께 bundle install을 실행하게 됩니다. + 카피스트라노 작업에서 변경할 수 있는 옵션의 목록은 cap -e bundle:install로 + 보실 수 있습니다. .bullet .description - %h3 Automatic deployment with Vlad - There is a default Vlad task available. To make it available, add this line - to the Vlad deploy.rb. + %h3 Vlad로 하는 자동 배포 + 기본 Vlad 작업으로 할 수 있습니다. 이 기능을 활성화하려면 Vlad의 deploy.rb에 + 다음 줄을 추가하세요. :code # lang: ruby require 'bundler/vlad' .notes - Once you have done that, the vlad:bundle:install task will be - available for use. Make sure it is run as part of your deploy. For example: + 넣으시면 vlad:bundle:install 작업이 사용가능하게 됩니다. + 배포의 일부분으로 동작하는지 확인하세요. 예를 들면 이런 식입니다. :code # lang: ruby task "vlad:deploy" => %w[ @@ -66,90 +64,86 @@ .bullet .description - %h3 After deploying - Make sure to use bundle exec to run any executables - from gems in the bundle + %h3 배포 이후 + 번들 안의 gem의 실행 파일을 실행할 때 bundle exec을 + 사용하는지 확인하세요. :code $ bundle exec rake db:setup .notes - Alternatively, you can use the --binstubs option on the - install command to generate executable binaries that can be used instead of - bundle exec. - = link_to 'Learn More: Executables', './man/bundle-exec.1.html' + 또는 --binstubs 옵션을 사용해 설치 명령이 bundle exec + 대신 사용 가능한 실행 파일 바이너리를 생성하도록 하세요. + = link_to '자세한 내용은: 실행 파일', './man/bundle-exec.1.html' .bullet .description %h3 Heroku - When you deploy to Heroku, Bundler will be run automatically as long as a Gemfile is present. If you check in your Gemfile.lock, Heroku will run `bundle install --deployment`. If you want to exclude certain groups using the --without option, you need to use `heroku config`. + Heroku에 배포할 때 Gemfile만 있다면 번들러는 자동으로 실행됩니다. Gemfile.lock 파일을 + 체크인했다면 Heroku는 `bundle install --deployment`를 실행 합니다. + --without 옵션을 사용해 특정 그룹을 제외하고 싶다면 `heroku config`을 + 사용하셔야 합니다. :code $ heroku config:add BUNDLE_WITHOUT="test development" --app app_name = link_to 'Heroku Bundler Documentation', 'http://docs.heroku.com/bundler' %h2#deploying-your-application - Deploying Your Application + 애플리케이션 배포하기 .bullet .description - When you run bundle install, bundler will (by default), install your gems - to your system repository of gems. This means that they will show up in gem - list. Additionally, if you are developing a number of applications, you will not - need to download and install gems in common for each application. This is nice for - development, but somewhat problematic for deployment. + bundle install을 실행할 때 번들러는 (기본 값으로) gem을 시스템 gem 저장소에 + 설치합니다. 이 말은 gem list에서 볼 수 있다는 의미입니다. 추가적으로 + 여러 애플리케이션을 개발 중이라면 각각의 애플리케이션에서 다운로드해 설치할 필요가 + 없습니다. 이렇게 하면 개발할 때는 편하지만 배포할 때는 다소 문제가 될 수 있습니다. %p.description - In a deployment scenario, the Unix user you deploy with may not have access to install - gems to a system location. Even if the user does (or you use sudo), the - user that boots the application may not have access to them. For instance, Passenger - runs its Ruby subprocesses with the user nobody, a somewhat restricted - user. The tradeoffs in a deployment environment lean more heavily in favor of isolation - (even at the cost of a somewhat slower deploy-time bundle install when some - third-party dependencies have changed). + 배포 시나리오에서 유닉스 사용자는 시스템 영역에 gem을 설치할 권한이 없을 것입니다. + 배포하는 사용자에게 권한이 있(거나 sudo를 사용한)다 하더라도 애플리케이션을 + 실행하는 사용자에게는 권한이 없을 수도 있습니다. 예를 들어 패신저는 루비 서브 프로세스를 + 제한된 사용자인 nobody로 실행합니다. + 배포 환경에서는 환경을 격리하는 데 보다 힘을 씁니다.(어떤 서드파티 의존성이 바뀌었을 때 + 배포 중에 bundle install이 느려진다고 해도 말이죠.) %p.description - As a result, bundler comes with a --deployment flag that encapsulates the - best practices for using bundler in a deployment environment. These practices are based - on significant feedback we have received during the development of bundler, as well as a - number of bug reports that mostly reflected a misunderstanding of how to best configure - bundler for deployment. The --deployment flags adds the following defaults: + 결과적으로 번들러를 --deployment 플래그와 함께 사용하면 배포환경에서 번들러를 + 사용하는 최선의 사례을 캡슐화합니다. 이 사례들은 번들러의 개발 기간 동안 받은 중요한 + 피드백뿐만 아니라, 버그 리포트를 기반으로 합니다. 버그 리포트의 대부분은 가장 적합한 + 배포를 위한 번들러를 구성하는 방법에 대한 오해를 반영하고 있습니다. + --deployment 플래그는 기본적으로 다음을 추가합니다. .description %ul %li - Instead of installing gems to the system location, bundler will install gems to - vendor/bundle inside your application. Bundler will transparently remember - this location when you invoke it inside your application (with - Bundler.setup and Bundler.require). + 시스템에 gem을 설치하는 대신 번들러는 애플리케이션 안의 vendor/bundle에 + 설치할 것입니다. 애플리케이션 안에서 (Bundler.setup과 + Bundler.require를 사용해) 번들러를 실행하면 번들러는 이 위치를 + 투명하게 기억할 것입니다. %li - Bundler will not use gems already installed to your system, even if they exist. + 번들러는 시스템에 설치된 gem이 이미 있다고 해도 사용하지 않을 것입니다. %li - If you have run bundle pack, checked in the vendor/cache - directory, and do not have any git gems, Bundler will not contact the internet while - installing your bundle. + bundle pack을 실행한 적이 있고 vendor/cache 디렉터리가 + 체크인 되어있고 git gem을 가지고 있지 않다면, 번들러는 번들을 설치할 때 인터넷에 + 접속하지 않을 것입니다. %li - Bundler will require a Gemfile.lock snapshot, and fail if you did not - provide one. + 번들러는 Gemfile.lock 스냅숏을 요청하고 없다면 실패합니다. %li - Bundler will not transparently update your Gemfile.lock if it is out of - date with your Gemfile + 번들러는 Gemfile이 오래된 버전이라 하더라도 Gemfile.lock을 + 갱신하지 않습니다. %p.description - If you use Capistrano, you should symlink vendor/bundle to - shared/vendor_bundle so that bundler will share your installed gems between - deployments (making things zippy if you didn't make any changes), but still give you the - benefits of isolation from other applications. + 카피스트라노를 사용하시고 계신다면 vendor/bundle을 + shared/vendor_bundle의 심볼릭 링크로 만드실 수 있습니다. 이렇게 하면 번들러는 + 배포판 사이에 설치된 gem을 공유해 (변경되지 않았다면 배포 과정을 단축하면서) 다른 + 애플리케이션과 격리되는 장점은 유지 할 수 있습니다. %p.description - By defaulting the bundle directory to vendor/bundle, and installing your - bundle as part of your deployment process, you can be sure that the same Unix user that - checked out your application also installed the third-party code your application needs. - This means that if Passenger (or Unicorn) can see your application, it can also see its - dependencies. + 기본적으로 번들 디렉터리는 vendor/bundle입니다. 그리고 배포 프로세스의 일부로 + 번들을 설치하면 애플리케이션을 체크아웃한 같은 유닉스 사용자들도 애플리케이션에서 필요한 + 서드파티 코드들이 설치되어 있는 것을 확인 할 수 있습니다. 이 말은 페신저(또는 유니콘)가 + 애플리케이션을 볼 수 있다면, 의존성도 볼 수 있다는 이야기입니다. %p.description - The --deployment flag requires an up-to-date Gemfile.lock to - ensure that the testing you have done (in development and staging) actually reflects the - code you put into production. You can run bundle check before deploying - your application to make sure that your Gemfile.lock is up-to-date. Note - that it will always be up-to-date if you have run bundle install, - successfully booted your application (or run your tests) since the last time you changed - your Gemfile. + --deployment 플래그는 실제로 프로덕션에 코드를 반영하기 전에 (개발과 스테이징 + 환경에서) 테스트가 끝난 최신의 Gemfile.lock을 필요로 합니다. 배포하기 전에 + bundle check를 실행해 Gemfile.lock이 최신 상태인지 확인할 수 + 있습니다. 마지막으로 Gemfile을 변경한 이후 bundle install을 실행하고 + 성공적으로 애플리케이션을 부트(하거나, 테스트를 실행)했다면 항상 최신 상태임을 주의하세요. diff --git a/source/v1.11/faq.haml b/source/v1.11/faq.haml index 9ba637e411..c316ae0752 100644 --- a/source/v1.11/faq.haml +++ b/source/v1.11/faq.haml @@ -1,167 +1,148 @@ %h2#faq - FAQ - Frequently Asked Questions + FAQ - 자주 묻는 질문 .contents .bullet .description %h3 - Why Can't I Just Specify Only = Dependencies? + =으로만 의존성을 설정하면 안 되나요? %p - Q: I understand the value of locking my gems down - to specific versions, but why can't I just specify = versions - for all my dependencies in the Gemfile and forget about - the Gemfile.lock? + Q: gem을 고정할 만한 가치가 있다고 생각합니다만, =으로만 + 버전을 적어 모든 의존성을 Gemfile에서 해결하고 Gemfile.lock을 + 안 쓸 수는 없을까요? %p - A: Many of your gems will have their own - dependencies, and they are unlikely to specify = dependencies. - Moreover, it is probably unwise for gems to lock down all of *their* - dependencies so strictly. The Gemfile.lock allows you to - specify the versions of the dependencies that your application needs in - the Gemfile, while remembering all of the exact versions of - third-party code that your application used when it last worked correctly. + A: gem은 각각의 의존성을 가집니다. 그리고 gem은 =으로 + 의존성을 설정하지 않을 가능성이 있습니다. 더욱이, 모든 *gem들*의 의존성을 너무 + 엄격하게 고정하는 것은 좋은 생각이 아닙니다. Gemfile.lock은 마지막으로 + 정상적으로 동작할 때의 애플리케이션의 모든 서드파티 코드를 정확히 기억하는 대신에, + 애플리케이션에서 필요로 하는 의존성의 버전을 Gemfile에 지정할 수 있도록 합니다. %p - By specifying looser dependencies in your Gemfile - (such as nokogiri ~> 1.4.2), you gain the ability to run - bundle update nokogiri, and let bundler handle updating **only** - nokogiri and its dependencies to the latest version that still - satisfied the ~> 1.4.2 version requirement. This also allows you - to say "I want to use the current version of nokogiri" (gem 'nokogiri' - in your Gemfile) without having to look up the exact version number, - while still getting the benefits of ensuring that your application always runs with - exactly the same versions of all third-party code. + nokogiri ~> 1.4.2처럼 Gemfile에서 느슨하게 의존성을 지정하면 + bundle update nokogiri를 실행해 ~> 1.4.2의 요구 버전 범위를 여전히 + 만족하는 nokogiri와 의존 gem**만** 업데이트할 수 있게 됩니다. + 또, 정확한 버전 번호를 모르더라도 Gemfile에서 gem 'nokogiri'라고 + 적어 "난 nokogiri의 최신 버전을 쓰고 싶어."라고 말할 수 있습니다. + 이 경우에도 여전히 애플리케이션이 서드파티 코드와 정확히 같은 버전으로 동작하는 것이 + 보장됩니다. %h3 - Why Can't I Just Submodule Everything? + 모든 걸 서브모듈로 관리하면 안 될까요? %p - Q: I don't understand why I need bundler to manage - my gems in this manner. Why can't I just get the gems I need and stick them - in submodules, then put each of the submodules on the load path? + Q: 왜 gem을 관리하는데 번들러가 필요한지 이해하지 못하겠습니다. + 그냥 gem을 받아서 서브모듈로 지정하고 각각의 서브모듈에 로드 경로를 지정하면 안 될까요? %p - A: Unfortunately, that solution requires that you - manually resolve all of the dependencies in your application, including dependencies - of dependencies. And even once you do that successfully, you would need to redo that - work if you wanted to update a particular gem. For instance, if you wanted to update - the rails gem, you would need to find all of the gems that depended on - dependencies of Rails (rack, erubis, i18n, - tzinfo, etc.), and find new versions that satisfy the new versions of - Rails' requirements. + A: 불행히도 그 해결책은 의존성의 의존성을 포함해서 모든 의존성을 + 수동으로 해결해야 할 필요가 있습니다. 한 번은 성공했다 하더라도, gem을 부분적으로 업데이트 + 할 때마다 재작업이 필요합니다. 예를 들어 rails gem을 업데이트 하려 한다면 + 레일스의 의존성을 위한 모든 gem(rack, erubis, i18n, + tzinfo 등)을 찾고 새 버전의 레일스의 의존성을 만족하는 버전을 찾을 필요가 + 있습니다. %p - Frankly, this is the sort of problem that computers are good at, and which you, - a developer, should not need to spend time doing. + 솔직히, 이 문제는 컴퓨터가 풀기 좋은 문제입니다. 개발자가 시간을 낭비할 필요는 없죠. %p - More concerningly, if you made a mistake in the manual dependency resolution - process, you would not get any feedback about conflicts between different dependencies, - resulting in subtle runtime errors. For instance, if you accidentally stuck the wrong - version of rack in a submodule, it would likely break at runtime, when - Rails or another dependency tried to rely on a method that was not present. + 더 걱정되는 것은, 수동 의존성 해결 과정에서 실수를 하면, 다른 의존성 간의 충돌에 대한 + 피드백 대신에 미묘한 런타임 에러를 받게 된다는 점입니다. 예를 들어 서브모듈에서 실수로 + 잘못된 rack 버전을 사용한다면, 레일스나 다른 의존성 관계의 gem이 + 존재하지 않는 메소드를 호출하려 해 정상적으로 실행되지 않습니다. %p %strong - Bottom line: + 결론: - even though it might seem simpler at first glance, it is decidedly significantly - more complex. + 처음엔 간단해 보일지 몰라도 확실히 더 복잡합니다. %h3 - Why Is Bundler Downloading Gems From --without Groups? + 왜 번들러가 --without 그룹 안에 있는 gem을 다운로드하죠? %p - Q: I ran bundle install --without production and - bundler is still downloading the gems in the :production group. Why? + Q: bundle install --without production을 실행했지만 + 번들러가 여전히 :production 그룹에 있는 gem을 다운로드 합니다. 왜죠? %p - A: Bundler's Gemfile.lock has to contain exact - versions of all dependencies in your Gemfile, regardless of any options - you pass in. If it did not, deploying your application to production might change all - your dependencies, eliminating the benefit of Bundler. You could no longer be sure that - your application uses the same gems in production that you used to develop and test with. - Additionally, adding a dependency in production might result in an application that is - impossible to deploy. + A: 번들러의 Gemfile.lock은 넘기는 옵션에 관계없이 + Gemfile의 모든 의존성에 대한 정확한 버전정보를 가지고 있습니다. 그렇게 + 안 한다면 프로덕션에 배포할 때 모든 의존성을 바꾸게 되고, 번들러의 장점을 없애게 될 + 것입니다. 더 이상 애플리케이션에서 개발, 테스트에 사용하는 gem이 프로덕션에서 + 사용하는 gem과 같은 gem이라는 확신을 못하게 됩니다. 덤으로 프로덕션의 의존성 추가는 + 배포 불가능 상태를 만들 수도 있습니다. %p - For instance, imagine you have a production-only gem (let's call it - rack-debugging) that depends on rack =1.1. If we did not evaluate - the production group when you ran bundle install --without production, you - would deploy your application, only to receive an error that rack-debugging - conflicted with rails (which depends on actionpack, which depends - on rack ~> 1.2.1). + 프로덕션에서만 사용하는 gem rack-debugging이 있다고 해봅시다. rack-debugging은 + rack =1.1에 의존합니다. bundle install --without production으로 + 실행할 때는 프로덕션 그룹이 평가되지 않지만, 애플리케이션을 배포할 때 rack-debugging이 + rails와 충돌한다는 메시지를 받게 될 것입니다. 왜냐하면 rails가 + 의존하는 actionpack은 rack ~> 1.2.1을 필요로 하기 때문입니다. %p - Another example: imagine a simple Rack application that has gem 'rack' - in the Gemfile. Again, imagine that you put rack-debugging in the - :production group. If we did not evaluate the :production group when - you installed via bundle install --without production, your app would use - rack 1.2.1 in development, and you would learn, at deployment time, that - rack-debugging conflicts with the version of Rack that you tested with. + 다른 예로 Gemfile에 gem 'rack'이 있는 간단한 Rack 애플리케이션이 + 있다고 해봅시다. 거기의 :production그룹에 rack-debugging을 + 넣었다고 하죠. bundle install --without production을 통해 설치했을 때는 + :production 그룹은 평가되지 않고 애플리케이션은 개발환경에서 + rack 1.2.1을 사용하게 됩니다. 그리고 이 상황은 이미 배우셨지만, + rack-debugging이 테스트했던 Rack의 버전과 충돌하게 됩니다. %p - In contrast, by evaluating the gems in **all** groups when you call bundle install, - regardless of the groups you actually want to use in that environment, we will discover the - rack-debugger requirement, and install rack 1.1, which is also compatible - with the gem 'rack' requirement in your Gemfile. + 반면에, bundle install을 호출할 때 환경에 상관없이 **모든** 그룹을 평가하면, + rack-debugger의 의존성을 발견하고 rack 1.1을 합니다. + rack 1.1은 Gemfile 안의 gem 'rack'과도 호환되죠. %p %strong - In short, - by always evaluating all of the dependencies in your Gemfile, regardless of the dependencies - you intend to use in a particular environment, you avoid nasty surprises when switching to a different - set of groups in a different environment. And because we just download (but do not install) the gems, - you won't have to worry about the possibility of a difficult **installation** process for a gem that - you only use in production (or in development). + 요약하자면, + Gemfile 안의 의존성과 관계없이 모든 의존성을 항상 평가함으로써, + 다른 환경에서 다른 그룹들을 사용하다 특정으로 환경을 바꾸려 할 때 발생할 수 있는 불편한 점을 미리 + 방지할 수 있습니다. 그리고 gem을 설치하지 않고 다운로드만 하므로, 프로덕션이나 개발 환경에서 + gem의 **설치** 프로세스가 어려워질 것을 걱정할 필요가 없습니다. %h3 - I Have a C Extension That Requires Special Flags to Install + 설치할 때 특별한 플래그가 필요한 C 확장이 있습니다. %p - Q: I have a C extension gem, such as mysql, which requires - special flags in order to compile and install. How can I pass these flags into the installation - process for those gems? + Q: mysql과 같은 설치할 때 특별한 플래그를 필요로 하는 C 확장 gem이 있습니다. + 설치할 때 어떻게 플래그 값을 넘길 수 있을까요? %p - A: First of all, this problem does not exist for the mysql2 - gem, which is a drop-in replacement for the mysql gem. In general, modern C extensions - properly discover the needed headers. + A: 먼저, mysql gem의 대용품(drop-in replacement)인 mysql2 gem을 + 사용하면 문제 없습니다. 일반적으로 요즘 C 확장들은 필요한 헤더를 찾을 수 있습니다. %p - If you really need to pass flags to a C extension, you can use the bundle config - command: + 만약 정말로 플래그를 넘길 필요가 있다면, bundle config 명령어를 사용하시면 됩니다. :code $ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config %p - Bundler will store this configuration in ~/.bundle/config, and bundler will use - the configuration for any bundle install performed by the same user. As a result, once - you specify the necessary build flags for a gem, you can successfully install that gem as many times - as necessary. + 번들러는 ~/.bundle/config에 설정을 저장할 것이고, 이 설정은 같은 사용자가 bundle install을 + 하면 매번 사용될 것입니다. 결과적으로 한 번만 필요한 gem에 빌드 플래그를 지정하면 그 gem은 언제나 성공적으로 + 설치 할 수 있습니다. %h3 - I Do Not Have an Internet Connection and Bundler Keeps Trying to Connect to the Gem Server + 인터넷에 접속할 수 없는 상황인데 계속 gem 서버에 연결을 시도합니다. %p - Q: I do not have an internet connection but I have installed the gem before. - How do I get bundler to use my local gem cache and not connect to the gem server? + Q: 지금 인터넷에 접속할 수 없지만, 이전에 gem을 설치해 두었습니다. + 어떻게 하면 번들러에서 gem 서버에 접속하지 않고 로컬 gem 캐시를 사용하게 할 수 있을까요? %p - A: Use the --local flag with bundle install. The --local flag tells bundler - to use the local gem cache instead of reaching out to the remote gem server. + A: bundle install 할 때 --local 플래그를 사용하시면 됩니다. --local 플래그는 번들러에게 + 원격 gem 서버 대신 로컬 gem 캐시를 사용하게 합니다. :code $ bundle install --local %h3 - Bundling From RubyGems is Really Slow + RubyGems 서버에서 번들러를 실행하면 매우 느립니다. %p - Q: When I bundle from rubygems it is really slow. Is there anything I can do to make it faster? + Q: rubygems 서버에서 번들러를 실행하면 매우 느립니다. 좀 더 빠르게 할 수는 없을까요? %p - A: Add the --full-index flag when bundling from the rubygems server. This downloads - the index all at once instead of making numerous small requests to the api. + A: rubygems 서버에서 번들러를 실행할 때 --full-index 플래그를 사용하세요. 이렇게 하면 + api에 매번 요청을 보내는 대신에 모든 인덱스를 한 번에 다운로드합니다. :code $ bundle install --full-index diff --git a/source/v1.11/gemfile.haml b/source/v1.11/gemfile.haml index 9f318f99a6..050750eaee 100644 --- a/source/v1.11/gemfile.haml +++ b/source/v1.11/gemfile.haml @@ -1,47 +1,50 @@ -%h2 In Depth +%h2 깊이 보기 .contents .bullet .description - Read the manual for an in-depth discussion of all of the options available in the - Gemfile and how to use them. - = link_to 'Gemfile manual', './man/gemfile.5.html' + Gemfile에서 사용 가능한 모든 옵션과 각 옵션의 상세한 사용법은 + 매뉴얼에 나와 있습니다. + = link_to 'Gemfile 매뉴얼', './man/gemfile.5.html' %h2 Gemfiles .contents .bullet .description - Gemfiles require at least one gem source, in the form of the URL for a RubyGems server. Generate a Gemfile with the default rubygems.org source by running bundle init. If you can, use https so your connection to the rubygems.org server will be verified with SSL. + Gemfile에는 최소한 하나의 gem 소스가 필요합니다. gem 소스에는 루비젬스 + 서버가 URL 형식으로 적혀있어야 합니다. bundle init을 + 실행함으로써 rubygems.org를 소스로 한 기본 값의 Gemfile을 만듭니다. 할 + 수만 있다면 https를 사용하여 rubygems.org 서버로의 연결이 SSL + 인증되도록 하세요. :code # lang: ruby source 'https://rubygems.org' .notes - It is possible, but not recommended as of Bundler 1.7, to add multiple global source lines. These are searched from last to first. + 여러 전역 소스를 추가하는 것은 가능하지만 번들러 1.7에서는 권장하지 + 않습니다. 이 소스들은 끝에서 처음 순으로 검색됩니다. .bullet .description - Some gem sources require a username and password. Use - bundle config to set the username and password for any - sources that need it. The command must be run once on each computer that - will install the Gemfile, but this keeps the credentials from being stored - in plain text in version control. + 어떤 gem 소스는 사용자 이름과 비밀번호가 필요합니다. 이를 + 위한 사용자 이름과 비밀번호를 설정하려면 bundle config를 + 사용하세요. 이 명령어는 Gemfile이 설치되는 각 컴퓨터에서 한 번은 실행해야 + 하지만, 버전 관리 시스템에 평문으로 인증 정보를 저장하지 않도록 합니다. :code $ bundle config https://gems.example.com/ user:password .description - For some sources, like a company Gemfury account, it may be easier to - simply include the credentials in the Gemfile as part of the source URL. + Gemfury 회사 계정 같은 어떤 소스는 인증을 Gemfile 안의 소스 URL의 일부로 + 포함시키는 것이 더 간단할 수도 있습니다. :code # lang: ruby source "https://user:password@gems.example.com" .description - Credentials in the source URL will take precedence over credentials set - using config. + 소스 URL 내의 인증은 config로 설정된 인증보다 우선됩니다. .bullet .description - Declare the gems that you need, including version numbers. Specify versions using the same - syntax that RubyGems supports for dependencies. + 필요한 gem을 버전 번호와 함께 선언합니다. 의존성을 지원하기 위한 버전 + 지정에는 루비젬스에서 사용하는 것과 같은 문법을 사용합니다. :code # lang: ruby gem 'nokogiri' @@ -49,41 +52,48 @@ gem 'rack', '>=1.0' gem 'thin', '~>1.1' .notes - Most of the version specifiers, like >= 1.0, are self-explanatory. - The specifier ~> has a special meaning, best shown by example. - ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. - ~> 2.1 is identical to >= 2.1 and < 3.0. - ~> 2.2.beta will match prerelease versions like 2.2.beta.12. - = link_to 'RubyGems version specifiers', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' + >= 1.0 같은 대부분의 버전 지정자는 따로 설명할 필요가 없습니다. + ~> 지정자는 특별한 의미가 있습니다. 예제로 설명하겠습니다. + ~> 2.0.3는 >= 2.0.3과 < 2.1를 함께 + 사용한 것과 같습니다. ~> 2.1은 >= 2.1과 + < 3.0을 함께 사용한 것과 같습니다. ~> 2.2.beta는 + 2.2.beta.12같은 사전 릴리스 버전과 일치합니다. + = link_to '루비젬스 버전 지정자', 'http://guides.rubygems.org/patterns/#pessimistic-version-constraint' .bullet .description - If a gem's main file is different than the gem name, specify how to require it. + gem의 메인 파일이 gem의 이름과 다르다면, require하는 방법을 지정할 필요가 + 있습니다. :code # lang: ruby gem 'rspec', :require => 'spec' gem 'sqlite3' .description - Specify :require => false to prevent bundler from requiring the gem, but still install it and maintain dependencies. + :require => false를 지정함으로써 번들러가 gem을 require하는 + 것을 방지할 수 있습니다. 하지만 여전히 설치와 의존성의 유지보수는 + 이루어집니다. :code # lang: ruby gem 'rspec', :require => false gem 'sqlite3' .notes - In order to require gems in your Gemfile, you will need to call - Bundler.require in your application. - = link_to 'Learn More: Bundler.require', './groups.html' + Gemfile 안의 gem을 require하려면, 애플리케이션에서 + Bundler.require를 호출할 필요가 있습니다. + = link_to '자세한 내용은: Bundler.require', './groups.html' .bullet .description - If some of your gems need to be fetched from a private gem server, this default source can be overridden for those gems. + 어떤 gem을 사설 gem 서버에서 가져와야 한다면, 이 기본 값 소스는 해당 + gem에서 덮어쓸 수 있습니다. - For a gem server that contains a single gem, it is easiest to use the :source option on that gem. + 한 gem을 가지고 있는 gem 서버를 위한 가장 간단한 방법은 그 gem에만 + :source 옵션을 사용하는 것입니다. :code # lang: ruby gem 'my_gem', '1.0', :source => 'https://gems.example.com' .description - If several gems come from the same server, you can use a source block to group them together. + 같은 서버에서 여러 gem을 받아야 한다면, source 블록을 사용해 + 그룹지을 수 있습니다. :code # lang: ruby source 'https://gems.example.com' do @@ -91,34 +101,39 @@ gem 'another_gem', '1.2.1' end .description - Credentials for gem servers can be specified either in the URL or using - bundle config, as described above. + gem 서버의 인증은 위에 설명한 것처럼 URL의 안이나 bundle + config를 사용해 지정할 수 있습니다. .bullet .description - Git repositories are also valid gem sources, as long as the repo contains one or - more valid gems. Specify what to check out with :tag, - :branch, or :ref. The default is the master branch. + git 저장소도 유효한 gem 소스입니다. 저장소가 하나 이상의 유효한 gem을 + 가지고 있다면 말이죠. :tag나 :branch, + :ref로 어느 걸 체크아웃할지 정할 수 있습니다. 기본 값은 + master 브랜치입니다. :code # lang: ruby gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git', :branch => '1.4' .notes - If the git repository does not contain a .gemspec file, bundler - will create a simple one, without any dependencies, executables or C extensions. - This may work for simple gems, but not work for others. If there is no .gemspec, - you probably shouldn't use the gem from git. - = link_to 'Learn more: Git', './git.html' + git 저장소가 .gemspec 파일을 가지고 있지 않다면, 번들러가 + 의존성, 실행 파일, C 확장 설정이 없는 간단한 .gemspec 파일을 + 생성합니다. 아마도 간단한 gem에서는 동작할 테지만, 동작하지 않을 수도 + 있습니다. .gemspec 파일이 없다면 git에서 gem을 사용하지 않는 + 것이 좋습니다. + = link_to '자세한 내용은: git', './git.html' .bullet .description - If you would like to use a unpacked gem directly from the filesystem, simply set the :path option to the path containing the gem's files. + 파일 시스템에서 직접 gem을 언팩하고 싶다면, :path 옵션에 gem의 + 파일이 들어있는 경로를 지정하면 간단합니다. :code # lang: ruby gem 'extracted_library', :path => './vendor/extracted_library' .bullet .description - If you would like to use multiple local gems directly from the filesystem, you can set a global `path` option to the path containing the gem's files. This will automatically load gemspec files from subdirectories. + 여러 로컬 gem을 파일 시스템에서 직접 사용하려 한다면, 전역 `path` 옵션에 + gem의 파일이 들어있는 경로를 설정할 수 있습니다. 이렇게 하면 하위 + 디렉터리에서 gemspec 파일을 자동으로 로드합니다. :code # lang: ruby path 'components' do @@ -128,7 +143,9 @@ .bullet .description - Dependencies can be placed into groups. Groups can be ignored at install-time (using --without) or required all at once (using Bundler.require). + 의존성은 그룹 안에 있을 수 있습니다. 그룹은 설치 시에 + 무시(--without을 사용)하거나 한 번에 + require(Bundler.require를 사용)할 수 있습니다. :code # lang: ruby gem 'wirble', :group => :development @@ -137,19 +154,25 @@ group :test do gem 'rspec' end - = link_to 'Learn more: Groups', './groups.html' + = link_to '자세한 내용은: 그룹', './groups.html' .bullet .description - You can specify the required version of Ruby in the Gemfile with ruby. If the Gemfile is loaded on a different Ruby version, Bundler will raise an exception with an explanation. + Gemfile에 ruby를 사용하여 필요한 루비 버전을 + 지정할 수 있습니다. Gemfile이 다른 루비 버전에서 로드 + 되었다면, 번들러는 설명과 함께 예외를 발생시킬 것입니다. :code # lang: ruby ruby '1.9.3' .bullet .description - What this means is that this app has a dependency to a Ruby VM that is ABI compatible with 1.9.3. If the version check does not match, Bundler will raise an exception. This will ensure the running code matches. You can be more specific with the :engine and :engine_version options. + 이것이 의미하는 것은 1.9.3과 ABI 호환이 있는 루비 VM에 의존성이 있다는 + 것입니다. 버전을 확인해 맞지 않으면, 번들러는 예외를 발생시킵니다. 이것은 + 실행 중의 코드가 매치하는지 확인합니다. :engine과 + :engine_version 버전 옵션을 사용해 좀 더 자세한 설정을 할 수 + 있습니다. :code # lang: ruby ruby '1.9.3', :engine => 'jruby', :engine_version => '1.6.7' - = link_to 'Learn More: Ruby Directive', './gemfile_ruby.html' + = link_to '자세한 내용은: 루비 지시자', './gemfile_ruby.html' diff --git a/source/v1.11/gemfile_ruby.haml b/source/v1.11/gemfile_ruby.haml index 15fc691d2c..13386b0035 100644 --- a/source/v1.11/gemfile_ruby.haml +++ b/source/v1.11/gemfile_ruby.haml @@ -1,9 +1,12 @@ -%h2 Specifying a Ruby Version +%h2 루비 버전 지정하기 .contents .bullet .description - Like gems, developers can setup a dependency on Ruby. This makes your app fail faster in case you depend on specific features in a Ruby VM. This way, the Ruby VM on your deployment server will match your local one. You can do this by using the ruby directive in the Gemfile: + 개발자는 gem처럼 루비의 의존성도 지정할 수 있습니다. + 이렇게 함으로써 애플리케이션이 루비 VM의 특정 기능에 의존하는 경우 빠르게 실패하도록 합니다. + 이런 식으로, 배포 서버의 루비 VM이 로컬의 루비와 일치하는지 확인할 수 있습니다. + 의존성 지정은 Gemfile에 ruby 지시자를 사용함으로써 할 수 있습니다. :code # lang: ruby ruby 'RUBY_VERSION', :engine => 'ENGINE', :engine_version => 'ENGINE_VERSION', @@ -11,34 +14,39 @@ .bullet .description - If you wanted to use JRuby 1.6.7 using Ruby 1.9.3, you would simply do the following: + 루비 1.9.3을 사용해 JRuby 1.6.7을 사용하고 싶을 때엔, 이렇게 하면 됩니다. :code # lang: ruby ruby '1.9.3', :engine => 'jruby', :engine_version => '1.6.7' .bullet#patchlevel .description - It's also possible to restrict the patchlevel of the Ruby used by doing the following: + 루비의 패치레벨을 제한하는 것도 가능합니다. :code # lang: ruby ruby '1.9.3', :patchlevel => '448' .bullet .description - Bundler will make checks against the current running Ruby VM to make sure it matches what is specified in the Gemfile. If things don't match, Bundler will raise an Exception explaining what doesn't match. + 번들러는 현재 실행 중인 루비 VM이 Gemfile 안에서 지정한 루비 버전과 일치하는지 확인합니다. + 일치하지 않는다면, 번들러는 일치하지 않음을 설명하는 예외를 발생시킵니다. :code Your Ruby version is 1.8.7, but your Gemfile specified 1.9.3 .bullet .description - Both :engine and :engine_version are optional. When these options are omitted, this means the app is compatible with a particular Ruby ABI but the engine is irrelevant. When :engine is used, :engine_version must also be specified. + :engine과 :engine_version은 선택적입니다. + 이 옵션을 생략할 경우, 이 애플리케이션이 특정 루비 ABI와 호환하지만 엔진은 무관하다는 의미가 됩니다. + :engine을 사용할 경우 반드시 :engine_version도 지정해야 합니다. .bullet .description - Using the platform command with the --ruby flag, you can see what ruby directive is specified in the Gemfile. + platform 명령어를 --ruby 플래그와 사용할 경우, Gemfile 안에 어떤 ruby 지시자가 지정되었는지 볼 수 있습니다. :code ruby 1.9.3 (jruby 1.6.7) - = link_to 'Learn More: bundle platform', './bundle_platform.html' + = link_to '자세한 내용은: bundle platform', './bundle_platform.html' .bullet .description - In the ruby directive, :patchlevel is optional, as patchlevel releases are usually compatible and include important security fixes. The patchlevel option checks the RUBY_PATCHLEVEL constant, and if not specified then bundler will simply ignore it. + ruby 지시자에서, :patchlevel은 선택적입니다. + 패치레벨 릴리스는 보통 호환가능하며 중요한 보안 픽스를 포함하고 있습니다. + 패치레벨 옵션은 RUBY_PATCHLEVEL 상수를 확인하며, 지정되어 있지 않으면 그냥 무시합니다. diff --git a/source/v1.11/git.haml b/source/v1.11/git.haml index 5a9a0216b0..4d5b8855e7 100644 --- a/source/v1.11/git.haml +++ b/source/v1.11/git.haml @@ -1,40 +1,35 @@ -%h2 Gems from git repositories +%h2 Git 저장소의 gem .contents .bullet .description - Bundler adds the ability to use gems directly from git repositories. Setting - them up is as easy as adding a gem to your Gemfile. Using the very latest - version of a gem (or even a fork) is just as easy as using an official - release. + 번들러는 git 저장소에서 직접 gem을 이용하는 기능을 추가했습니다. Gemfile에 + gem을 넣는 것만큼 설정하기 쉽습니다. 최신 버전의 gem(이나 포크)도 + 정식 릴리스만큼 쉽게 사용하실 수 있습니다. .description - Because RubyGems lacks the ability to handle gems from git, any gems - installed from a git repository will not show up in gem list. - They will, however, be available after running Bundler.setup. + 루비젬에는 git에 있는 gem을 제어할 수 있는 기능이 없으므로 git 저장소에서 + 설치한 gem은 gem list에서는 보이지 않을 것입니다. 하지만 + Bundler.setup을 실행하면 사용 가능합니다. .bullet .description - Specify that a gem should come from a git - repository with a .gemspec at its root + gem으로 사용하려면 git 저장소 루트에 .gemspec 파일이 있어야 합니다. :code # lang: ruby gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git' .bullet .description - If there is no .gemspec at the root of - a git repository, you must specify a version - that bundler should use when resolving - dependencies + git 저장소의 루트에 .gemspec 파일이 없다면 번들러가 의존성을 해결할 + 때 사용할 버전을 지정해야 합니다. :code # lang: ruby gem 'deep_merge', '1.0', :git => 'https://github.com/peritor/deep_merge.git' .bullet .description - Specify that a git repository containing - multiple .gemspec files should be treated - as a gem source + git 저장소가 여러 .gemspec 파일을 가지고 있다면 gem 소스와 같은 + 취급을 합니다. :code # lang: ruby git 'https://github.com/rails/rails.git' do @@ -45,8 +40,7 @@ .bullet .description - Specify that a git repository should use - a particular ref, branch, or tag + git 저장소는 특정 ref, branch, tag만 사용합니다. :code # lang: ruby :git => 'https://github.com/rails/rails.git', :ref => '4aded' @@ -55,9 +49,7 @@ .bullet .description - Specifying a ref, branch, or tag for a - git repository specified inline works - exactly the same way + git 저장소의 ref, branch, tag를 한 줄로 지정해도 똑같이 동작합니다. :code # lang: ruby gem 'nokogiri', :git => 'https://github.com/tenderlove/nokogiri.git', :ref => '0eec4' @@ -73,88 +65,88 @@ .bullet .description - Specify that the submodules from a git repository - also should be expanded by bundler + submodules 옵션을 지정해서 번들러가 git 저장소의 서브모듈을 가져오게 할 수도 있습니다. :code # lang: ruby gem 'rugged', :git => 'git://github.com/libgit2/rugged.git', :submodules => true .bullet .description - If you are getting your gems from a public GitHub repository, - you can use the shorthand + 공개된 GitHub 저장소에서 gem을 가져오는 경우에는 축약해서 쓸 수 있습니다. :code # lang: ruby gem 'nokogiri', :github => 'tenderlove/nokogiri' .description - If the repository name is the same as the GitHub account hosting it, - you can omit it + 만약 GitHub 계정의 이름과 저장소의 이름이 같다면 생략할 수 있습니다. :code # lang: ruby gem 'rails', :github => 'rails' .description - NB: This shorthand can only be used for public repos in Bundler version 1.x. Use HTTPS for read and write: + NB: 이 단축은 번들러 1.x버전의 공개 저장소일 경우에만 사용할 수 + 있습니다. 읽기, 쓰기를 할 경우는 대신 HTTPS를 사용하세요. :code # lang: ruby gem 'rails', :git => 'https://github.com/rails/rails' .description - All of the usual :git options apply, like :branch and :ref. + :branch와 :ref처럼 :git에서 보통 + 사용하는 옵션이 적용됩니다. :code # lang: ruby gem 'rails', :github => 'rails', :ref => 'a9752dcfd15bcddfe7b6f7126f3a6e0ba5927c56' .description - There are analogous shortcuts for Bitbucket (:bitbucket) and GitHub Gists (:gist). + Bitbucket(:bitbucket), GitHub Gists(:gist)에도 + 비슷한 단축이 있습니다. :code # lang: ruby gem 'capistrano-sidekiq', :github => 'seuros/capistrano-sidekiq' gem 'keystone', :bitbucket => 'musicone/keystone' -%h2 Custom git sources +%h2 사용자 정의 git 소스 .contents .bullet .description - The :github shortcut used above is one of Bundler's built in git sources. Bundler comes - with shortcuts for :github, :gist, and :bitbucket, but you can - also add your own. + 위에 사용된 :github 단축은 번들러의 내장 git 소스 중 하나입니다. + 번들러에는 :github, :gist, :bitbucket이 + 이미 들어있고 추가도 할 수 있습니다. .description - If you're using Github Enterprise, Stash, or just have a custom git setup, create your own shortcuts - by calling git_source before you use your custom option. Here's an example for Stash: + Github 엔터프라이즈, Stash, 사용자 정의 git 설정을 사용 중이라면, 사용자 정의 + 옵션을 사용하기 전에 git_source를 호출해 사용자 정의 단축을 만들 + 수 있습니다. 여기에 Stash의 예제가 있습니다. :code # lang: ruby git_source(:stash){ |repo_name| "https://stash.corp.acme.pl/\#{repo_name}.git" } gem 'rails', :stash => 'forks/rails' -%h2 Security +%h2 보안 .contents .bullet .description - http:// and git:// URLs are insecure. A - man-in-the-middle attacker could tamper with the code as you check it out, - and potentially supply you with malicious code instead of the code you meant to - check out. Because the :github shortcut uses a git:// - URL in Bundler 1.x versions, we recommend using using HTTPS URLs or overriding - the :github shortcut with your own HTTPS git source. + http://와 git:// URL은 안전하지 않습니다. + 중계 공격자(man-in-the-middle attacker)는 체크아웃할 때 코드를 변조할 수 있고 + 원래 체크아웃 하려 했던 코드 대신 악의적인 코드를 제공할 가능성이 있습니다. + 번들러 1.x 버전에서 :github 단축이 git:// URL을 + 사용하기 때문에, HTTPS URL을 사용하거나 :github 단축을 재정의해 + HTTPS git 소스를 사용하시길 추천 합니다. -%h2#local Local Git Repos +%h2#local 로컬 Git 저장소 .contents .bullet .description - Bundler also allows you to work against a git repository locally - instead of using the remote version. This can be achieved by setting - up a local override: + 번들러는 리모트 버전을 사용하는 대신에 로컬 git 저장소를 사용하도록 + 할 수도 있습니다. 로컬 오버라이드를 설정하면 됩니다. :code bundle config local.GEM_NAME /path/to/local/git/repository .bullet .description - For example, in order to use a local Rack repository, a developer could call: + 예를 들어 로컬 Rack 저장소를 사용하려면 이렇게 호출합니다. :code bundle config local.rack ~/Work/git/rack .description - and setup the git repo pointing to a branch: + 그리고 git 저장소의 브랜치를 지정합니다. :code # lang: ruby gem 'rack', :github => 'rack/rack', :branch => 'master' @@ -162,31 +154,30 @@ .bullet .description %p - Now instead of checking out the remote git repository, the local - override will be used. Similar to a path source, every time the local - git repository change, changes will be automatically picked up by - Bundler. This means a commit in the local git repo will update the - revision in the Gemfile.lock to the local git repo revision. This - requires the same attention as git submodules. Before pushing to - the remote, you need to ensure the local override was pushed, otherwise - you may point to a commit that only exists in your local machine. + 이제 리모트 git 저장소를 체크아웃하는 대신에 로컬 오버라이드가 + 사용됩니다. 경로(path) 소스와 비슷하게 git 저장소가 변경될 때마다 + 변경사항이 번들러에 의해 자동으로 반영됩니다. 이 말은 로컬 git + 저장소에 커밋이 추가되면 Gemfile.lock 안의 리비전이 갱신 + 된다는 뜻입니다. 이렇게 하면 git 서브모듈을 사용하는 것과 같은 + 주의가 필요합니다. 리모트에 푸시하기 전에 로컬 오버라이드가 + 푸시되었는지 확인해야 합니다. 그렇지 않다면 로컬 기기에만 있는 + 커밋을 지정하게 됩니다. %p - Bundler does many checks to ensure a developer won't work with - invalid references. Particularly, we force a developer to specify - a branch in the Gemfile in order to use this feature. If the branch - specified in the Gemfile and the current branch in the local git - repository do not match, Bundler will abort. This ensures that - a developer is always working against the correct branches, and prevents - accidental locking to a different branch. + 번들러는 개발자가 유효하지 않은 참조를 사용하지 않도록 많은 검사를 + 수행합니다. 특히 이 기능을 사용할 때는 Gemfile에 브랜치를 + 지정하도록 강제합니다. Gemfile에 적혀있는 브랜치와 + 로컬 git 저장소의 현재 브랜치가 다르다면 번들러는 중단됩니다. + 언제나 올바른 브랜치에서 작업하는지 확인하고 다른 브랜치를 사용할 때 + 발생할 수 있는 사고를 예방할 수 있습니다. %p - Finally, Bundler also ensures that the current revision in the - Gemfile.lock exists in the local git repository. By doing this, Bundler - forces you to fetch the latest changes in the remotes. + 마지막으로 번들러는 Gemfile.lock 안의 현재 리비전이 + 로컬 git 저장소에도 있는지 확인합니다. 이렇게 함으로써 번들러는 + 리모트의 최신 변경 사항을 가져오도록 강제 할 수 있습니다. .bullet .description - %p If you do not want bundler to make these branch checks, you can override it by setting this option: + %p 번들러가 브랜치를 확인하길 원치 않는다면 이 옵션을 오버라이드 하세요. :code bundle config disable_local_branch_check true diff --git a/source/v1.11/groups.haml b/source/v1.11/groups.haml index d176cff654..99e374aa8b 100644 --- a/source/v1.11/groups.haml +++ b/source/v1.11/groups.haml @@ -1,14 +1,13 @@ -%h2 Using Groups +%h2 그룹 사용하기 .contents .bullet .description - Grouping your dependencies allows you - to perform operations on the entire - group. + 의존성을 그룹화하면 전체 그룹에 대한 + 작업을 수행할 수 있습니다. :code # lang: ruby - # These gems are in the :default group + # 이 gem들은 :default 그룹에 포함됩니다. gem 'nokogiri' gem 'sinatra' @@ -28,53 +27,50 @@ .bullet .description - Install all gems, except those in the - listed groups. Gems in at least one - non-excluded group will still be installed. + 나열된 그룹을 제외한 모든 gem을 설치합니다. + 제외되지 않은 그룹에 속해 있는 gem들은 여전히 + 설치됩니다. :code $ bundle install --without test development .bullet .description - Require the gems in particular groups, - noting that gems outside of a named group - are in the :default group + 특정 그룹을 요청(require)할 때, 명명된 그룹 + 밖의 gem은 :default 그룹인 것에 주의합시다. :code # lang: ruby Bundler.require(:default, :development) .bullet .description - Require the default gems, plus the gems - in a group named the same as the current - Rails environment + 기본 그룹과 현재 레일스 환경과 같은 이름의 + 그룹의 gem을 요정합니다. :code # lang: ruby Bundler.require(:default, Rails.env) .bullet .description - Restrict the groups of gems that you - want to add to the load path. Only gems - in these groups will be require'able + 로드 경로에 넣고 싶은 gem을 제한합니다. + 그 그룹에 포함된 gem만 요청가능합니다. :code # lang: ruby require 'rubygems' require 'bundler' Bundler.setup(:default, :ci) require 'nokogiri' - = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + = link_to '자세한 내용은: Bundler.setup', './bundler_setup.html' %h2#grouping-your-dependencies - Grouping Your Dependencies + 의존성을 그룹화하기 .bullet .description - You'll sometimes have groups of gems that only make sense in particular environments. - For instance, you might develop your app (at an early stage) using SQLite, but deploy it - using mysql2 or pg. In this example, you might not have MySQL - or Postgres installed on your development machine, and want bundler to skip it. + 가끔 특정 환경에만 맞는 gem의 그룹이 있습니다. 예를 들어, 초기 단계에 SQLite를 사용해 + 애플리케이션을 개발했지만, 배포할 때는 mysql2나 pg를 + 사용할 경우가 있습니다. 이 경우, 아마도 개발 환경에는 MySQL이나 Postgres가 + 안 깔려 있고 번들러에서 이를 생략하길 원할 것입니다. - To do this, you can group your dependencies: + 이렇게 하려면, 의존성을 그룹지으면 됩니다. :code # lang: ruby @@ -94,44 +90,44 @@ .bullet .description - Now, in development, you can instruct bundler to skip the production group: + 이제, 개발환경에서 번들러에게 production 그룹을 무시하도록 지시할 수 있습니다. :code $ bundle install --without production .bullet .description - Bundler will remember that you installed the gems using --without - production. For curious readers, bundler stores the flag in - APP_ROOT/.bundle/config. You can see all of the settings that bundler saved - there by running bundle config, which will also print out global settings - (stored in ~/.bundle/config), and settings set via environment variables. - For more information on configuring bundler, please see: + 번들러는 --without production을 사용하여 설치한 것을 기억합니다. + 호기심이 많은 독자를 위해 말하자면, 번들러는 APP_ROOT/.bundle/config에 + 플래그를 저장합니다. 모든 저장된 번들러의 옵션을 확인하고 싶으시면, + bundle config을 실행하시면 됩니다. 이 명령어는 + (~/.bundle/config 안에 저장된) 전역 설정과 환경변수에 의한 설정도 출력합니다. + 번들러 설정에 관한 더 자세한 정보는 밑의 링크를 확인해 주세요. #{link_to 'bundle config', './bundle_config.html'} .bullet %p.description - If you run bundle install later, without any flags, bundler will remember - that you last called bundle install --without production, and use that flag - again. When you require 'bundler/setup', bundler will ignore gems in these - groups. + 나중에 bundle install을 플래그 없이 실행 한다면, 번들러는 전에 부른 + bundle install --without production 명령어를 기억해 두었다가 이 플래그를 + 다시 사용합니다. require 'bundler/setup'할 때, 번들러는 그 그룹의 gem을 + 무시합니다. %p.description - You can also specify which groups to automatically require through the parameters to - Bundler.require. The :default group includes all gems not - listed under any group. If you call Bundler.require(:default, :development), - bundler will require all the gems in the :default group, as - well as the gems in the :development group. + 매개변수를 통해 Bundler.require에 사용할 그룹을 자동으로 지정하게 할 수도 + 있습니다. :default 그룹은 어떤 그룹에도 포함되지 않은 모든 gem을 가리킵니다. + Bundler.require(:default, :development)를 불렀다면, 번들러는 + :default 그룹의 모든 gem과 :development 그룹의 모든 gem을 + require합니다. %p.description - By default, a Rails generated app calls Bundler.require(:default, - Rails.env) in your application.rb, which links the groups in your - Gemfile to the Rails environment. If you use other groups (not linked to a - Rails environment), you can add them to the call to Bundler.require, if you - want them to be automatically required. + 기본 값으로, 레일스는 application.rb에서 + Bundler.require(:default, Rails.env)를 부르는 애플리케이션을 생성합니다. + Rails.env는 Gemfile 안의 그룹을 레일스 환경과 연결합니다. + 레일스 환경과 연결되지 않은 다른 그룹을 사용한고 자동으로 요청(require)하길 원한다면, + Bundler.require를 부름으로써 그 그룹을 추가할 수 있습니다. %p.description - Remember that you can always leave groups of gems out of Bundler.require, - and then require them manually using Ruby's require at the appropriate - place in your app. You might do this because requiring a certain gem takes some time, - and you don't need it every time you boot your application. + Bundler.require에서 gem 그룹을 제외하고 루비의 require를 이용해 + 적당한 곳에서 수동으로 요청할 수도 있다는 것을 기억하세요. + 아마도 특정 gem을 사용하는데 시간이 걸리거나, 부팅할 때마다 로드할 필요 없는 경우에 이 방법을 + 사용할 수 있습니다. diff --git a/source/v1.11/index.haml b/source/v1.11/index.haml index 170e2f1d04..63894d0213 100644 --- a/source/v1.11/index.haml +++ b/source/v1.11/index.haml @@ -1,33 +1,33 @@ %h2 What is Bundler? %p#intro - Bundler provides a consistent environment for Ruby projects by tracking - and installing the exact gems and versions that are needed. + 번들러는 필요한 정확한 gem과 버전을 추적하고 설치하여 루비 프로젝트를 위한 + 일관된 환경을 제공합니다. %br %br - Bundler is an exit from dependency hell, and ensures that the gems - you need are present in development, staging, and production. - Starting work on a project is as simple as bundle install. + 번들러는 의존성 지옥에서 벗어나게 하고, 필요한 gem이 개발, 스테이징, 프로덕션에 + 있는지 확인해 줍니다. + bundle install을 실행해 간단히 프로젝트에서 사용해 보세요. .buttons = link_to 'What\'s new in Bundler', './whats_new.html' = link_to 'Why Bundler exists', './rationale.html' %h2#getting-started - Getting Started + 시작하기 .contents .bullet .description %p - Getting started with bundler is easy! Open a terminal window and run this command: + 번들러는 배우기 쉽습니다! 터미널을 열고 이 명령어를 실행하세요. :code $ gem install bundler .bullet .description %p - Specify your dependencies in a Gemfile in your project's root: + 프로젝트의 최상위 디렉터리의 Gemfile에 의존성을 기술하세요. :code # lang: ruby source 'https://rubygems.org' @@ -39,66 +39,65 @@ .bullet .description %p - Install all of the required gems from your specified sources: + 지정한 소스로부터 필요한 모든 gem을 설치하세요. :code $ bundle install $ git add Gemfile Gemfile.lock - = link_to 'Learn More: bundle install', './bundle_install.html' + = link_to '자세한 내용은: bundle install', './bundle_install.html' .notes %p - The second command adds the Gemfile and Gemfile.lock to your repository. This ensures - that other developers on your app, as well as your deployment environment, will all use - the same third-party code that you are using now. + 두 번째 명령어는 저장소에 Gemfile, Gemfile.lock 파일을 추가합니다. 이렇게 해두면 배포 + 환경, 애플리케이션의 다른 개발자 모두 지금 사용 중인 서드파티 코드를 사용하도록 할 수 + 있습니다. .bullet .description %p - Inside your app, load up the bundled environment: + 애플리케이션의 안에서, 번들이 적용된 환경 로드하기 :code # lang: ruby require 'rubygems' require 'bundler/setup' - # require your gems as usual + # 평소처럼 gem을 require하세요 require 'nokogiri' - = link_to 'Learn More: Bundler.setup', './bundler_setup.html' + = link_to '자세한 내용은: Bundler.setup', './bundler_setup.html' .bullet .description %p - Run an executable that comes with a gem in your bundle: + 번들 안의 gem에 들어있는 실행 파일 실행하기 :code $ bundle exec rspec spec/models .notes %p - In some cases, running executables without bundle exec - may work, if the executable happens to be installed in your system - and does not pull in any gems that conflict with your bundle. + 어떤 때는, bundle exec 없이도 실행 파일을 실행할 수 있습니다. + 번들러 안의 어떤 gem과도 충돌하지 않고 시스템에 실행 파일이 설치되어 + 있는 경우가 그 경우죠. %p - However, this is unreliable and is the source of considerable pain. - Even if it looks like it works, it may not work in the future or - on another machine. + 하지만 이 상황은 신뢰하기 힘들고 고통의 근원이 됩니다. + 동작하는 것처럼 보이더래도, 다른 기기에서나 미래에 움직이지 않게 될 + 가능성이 있습니다. .description %p - Finally, if you want a way to get a shortcut to gems in your bundle: + 마지막으로, 원한다면 번들 안의 gem의 단축 실행 파일을 만들 수 있습니다. :code $ bundle install --binstubs $ bin/rspec spec/models .notes %p - The executables installed into bin are scoped to the - bundle, and will always work. - = link_to 'Learn More: Executables', './man/bundle-exec.1.html' + bin 안의 실행 파일들은 번들로 스코프되고 항상 동작합니다. + = link_to '자세한 내용은: Executables', './man/bundle-exec.1.html' -%h2#create-gem Create a rubygem with Bundler +%h2#create-gem 번들러로 루비젬 만들기 %p - Bundler is also an easy way to create new gems. Just like you might create a standard Rails project using rails new, you can create a standard gem project with bundle gem. + 번들러로 새로운 gem을 쉽게 만들 수도 있습니다. rails new로 새로운 레일스 프로젝트를 만드는 것처럼, bundle gem으로 일반적인 gem 프로젝트를 만들 수 있습니다. .bullet .description %p - Create a new gem with a README, .gemspec, Rakefile, directory structure, and all the basic boilerplate you need to describe, test, and publish a gem: + 설명, 테스트, 배포에 필요한 README, .gemspec, Rakefile, 디렉터리 구조, 모든 기본 뼈대를 포함해 gem을 만듭니다. :code $ bundle gem my_gem Creating gem 'my_gem'... @@ -118,23 +117,23 @@ create my_gem/test/my_gem_test.rb Initializing git repo in ./my_gem - = link_to 'Learn More: bundle gem', './bundle_gem.html' + = link_to '자세한 내용은: bundle gem', './bundle_gem.html' -%h2#use-bundler Use Bundler with +%h2#use-bundler 번들러와 함께 사용할 수 있는 것들 .buttons - = link_to 'Rails 3', './rails3.html' - = link_to 'Rails 2.3', './rails23.html' - = link_to 'Sinatra', './sinatra.html' - = link_to 'RubyGems', './rubygems.html' - = link_to 'RubyMotion', './rubymotion.html' + = link_to '레일스 3', './rails3.html' + = link_to '레일스 2.3', './rails23.html' + = link_to '시나트라', './sinatra.html' + = link_to '루비젬스', './rubygems.html' + = link_to '루비모션', './rubymotion.html' -%h2#get-involved Get involved +%h2#get-involved 기여하기 %p - Bundler has a lot of contributors and users, and they all talk to each other quite a bit. If you have questions, try #{link_to 'the IRC channel', 'http://webchat.freenode.net/?channels=bundler'} or #{link_to 'mailing list', 'http://groups.google.com/group/ruby-bundler'}. If you're interested in contributing to the project (no programming skills needed), read #{link_to 'the contributing guide', 'https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md'}. While participating in the Bundler project, please keep the #{link_to 'code of conduct', '/conduct.html'} in mind, and be inclusive and friendly towards everyone. If you have sponsorship or security questions, please contact the core team directly. - + 번들러는 많은 기여자와 사용자를 가지고 있고 상당히 많이 논의되고 있습니다. 질문이 있으시다면, #{link_to 'IRC 채널', 'http://webchat.freenode.net/?channels=bundler'}이나 #{link_to '메일링 리스트', 'http://groups.google.com/group/ruby-bundler'}에 해보세요. 프로젝트에 기여하는데 관심이 있으시다면(프로그래밍 스킬은 필요 없습니다), #{link_to '기여하기 가이드', 'https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md'}를 읽으세요. 번들러 프로젝트에 참여하는 동안, #{link_to '행동 강령', '/conduct.html'}을 명심하고, 모두에게 포용적이고 우호적으로 행동해 주시길 바랍니다. 스폰서를 하실 생각이 있으시거나 보안 관련 질문이 있으시면, 코어 팀에 직접 연락 주세요. + .buttons - = link_to 'Code of Conduct', '/conduct.html' - = link_to '#bundler on IRC', 'http://webchat.freenode.net/?channels=bundler' - = link_to 'Mailing list', 'http://groups.google.com/group/ruby-bundler' - = link_to 'Contributing', 'https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md' - = link_to 'Email core team', 'mailto:team@bundler.io' + = link_to '행동 강령', '/conduct.html' + = link_to 'IRC의 #bundler 채널', 'http://webchat.freenode.net/?channels=bundler' + = link_to '메일링 리스트', 'http://groups.google.com/group/ruby-bundler' + = link_to '기여하기', 'https://github.com/bundler/bundler/blob/master/DEVELOPMENT.md' + = link_to '코어 팀 메일 주소', 'mailto:team@bundler.io' diff --git a/source/v1.11/rails23.haml b/source/v1.11/rails23.haml index 280641fa08..4ce797a054 100644 --- a/source/v1.11/rails23.haml +++ b/source/v1.11/rails23.haml @@ -1,27 +1,27 @@ #intro - Rails 2.3 comes with its own gem handling. We're going to - override that and replace it with support for Bundler. + 레일스 2.3은 독자적으로 gem을 관리합니다. 하지만 번들러 설정을 + 덮어씌워 번들러를 지원하게 할 수 있습니다. .notes - NB: This may work with Rails versions lower than 2.3. - The Bundler team has not tested those versions, and will not provide - support for anyone on Rails older than 2.3, but feel free to try it. :) + NB: 아마도 2.3보다 낮은 버전의 레일스에서 움직일 수 있지만, + 번들러 팀에서는 테스트하지 않았고 2.3보다 낮은 버전의 레일스를 + 지원할 계획도 없습니다. 하지만 시도는 자유죠. :) -%h2 Using Bundler with Rails 2.3 +%h2 번들러를 레일스 2.3과 사용하기 .contents .bullet .description - If you don't have a Rails 2.3 app yet, generate one + 레일스 2.3 앱이 아직없다면, 생성합니다. :code $ rails myapp $ cd myapp .bullet .description - Insert the following code at the bottom of config/boot.rb, - right above the line `Rails.boot!` + config/boot.rb의 밑에 있는 + Rails.boot!의 바로 다음 줄에 아래 코드를 넣으세요. :code # lang: ruby class Rails::Boot @@ -40,9 +40,9 @@ .bullet .description - Create a new file, config/preinitializer.rb, - and insert the following. That is config NOT - config/initializers. + 새 파일 config/preinitializer.rb를 생성해, + 밑의 코드를 넣으세요. config입니다. + config/initializers가 아닙니다. :code # lang: ruby begin @@ -68,10 +68,10 @@ .bullet .description - Get all config.gem declarations from your application, and place - them into the Gemfile. If you have declarations in development.rb, - for instance, place them in a named group. Make sure to include - Rails itself and a default gem source. + 애플리케이션에 선언된 모든 config.gem을 Gemfile에 넣습니다. + development.rb 안에 (다른 환경의 경우라도) 선언이 있다면 선언들을 + 그 이름의 그룹에 넣으세요. 레일스 자신과 적어도 한 개 이상의 소스가 + 있는지도 확인하세요. :code # lang: ruby source 'https://rubygems.org' @@ -92,13 +92,13 @@ # gem 'rspec' # gem 'faker' end - = link_to 'Learn More: Groups', './groups.html' + = link_to '자세한 내용은: 그룹', './groups.html' .bullet .description - Once you have everything set up, you can use script/console, - script/server, and other Rake tasks as usual. From this point - on, you can follow the instructions in the Rails 3 guide + 한 번 전부 설정했다면, script/console, script/server나 다른 + 레이크 작업들도 평범하게 사용할 수 있습니다. 여기서부터는 + 레일스 3의 가이드를 읽으시면 됩니다. :code - $ bundle exec rake db:migrate - = link_to 'Learn More: Rails 3', './rails3.html#shared_with_23' + $ rake db:migrate + = link_to '자세한 내용은: 레일스 3', './rails3.html#shared_with_23' diff --git a/source/v1.11/rails3.haml b/source/v1.11/rails3.haml index e68b6599b6..4d2e2d6945 100644 --- a/source/v1.11/rails3.haml +++ b/source/v1.11/rails3.haml @@ -1,39 +1,37 @@ #intro - Rails 3 comes with baked in support with bundler. + 레일스 3은 기본적으로 번들러를 지원합니다. -%h2 Using Bundler with Rails 3 +%h2 번들러를 레일스 3과 사용하기 .contents .bullet .description - Install Rails as you normally would. Use sudo - if you would normally use sudo to install gems. + 평범하게 레일스를 설치하세요. 평소에 gem을 설치할 때 + sudo로 쓰신다면 sudo도 사용해 주세요. .how :code $ gem install rails .notes - We recommend using rvm for dependable Ruby - installations, especially if you are switching - between different versions of Ruby + 다른 루비 버전을 사용하실 일이 있다면, 신뢰할 수 + 있는 루비 설치관리를 위해 rvm을 추천합니다. .bullet .description - Generate a Rails app as usual + 평소처럼 레일스 앱을 생성합니다. :code $ rails new myapp $ cd myapp .bullet .description - Run the server. Bundler is transparently managing - your dependencies! + 서버를 실행합니다. 이미 번들러는 의존성을 투명하게 + 관리하고 있습니다! :code $ rails server .bullet .description - Add new dependencies to your Gemfile as you - need them. + 필요한 새 의존성을 Gemfile에 추가합니다. :code # lang: ruby gem 'nokogiri' @@ -41,9 +39,8 @@ .bullet .description - If you want a dependency to be loaded only in - a certain Rails environment, place it in a group - named after that Rails environment + 특정 레일스 환경에서만 로드하고 싶은 의존성이 있다면, + 레일스 환경을 이름으로 한 그룹에 넣으세요. :code # lang: ruby group :test do @@ -53,24 +50,23 @@ .bullet#shared_with_23 .description - You can place a dependency in multiple groups - at once as well + 한 번에 여러 그룹에 의존성을 넣을 수도 있습니다. :code # lang: ruby group :development, :test do gem 'wirble' gem 'ruby-debug' end - = link_to 'Learn More: Groups', './groups.html' + = link_to '자세한 내용은: 그룹', './groups.html' .bullet .description - After adding a dependency, if it is not yet - installed, install it + 의존성을 추가하고 아직 설치하지 않았다면 + 설치하세요. .how :code $ bundle install .notes - This will update all dependencies in your - Gemfile to the latest versions that do not - conflict with other dependencies + 이 명령은 Gemfile 안의 모든 의존성을 + 다른 의존성과 충돌하지 않는 최신 버전으로 + 갱신합니다. diff --git a/source/v1.11/rationale.haml b/source/v1.11/rationale.haml index ff935ea63a..5f3467ffe8 100644 --- a/source/v1.11/rationale.haml +++ b/source/v1.11/rationale.haml @@ -1,14 +1,14 @@ #intro - If you just want to know our recommended workflow, and don't care about the rationale, feel - free to jump to the summary below. + 추천하는 작업 흐름이 알고 싶을 뿐이고 근거에 관심이 없다면, 밑에 있는 + 요약만 보셔도 됩니다. %br #standalone %h2#bundlers-purpose-and-rationale - Bundler's Purpose and Rationale + 번들러의 목적과 근거 %p - First, you declare these dependencies in a file at the root of your application, called - Gemfile. It looks something like this: + 먼저, 이 의존성을 애플리케이션의 루트에 Gemfile이란 파일로 + 정의했습니다. 내용은 이렇습니다. :code # lang: ruby @@ -19,31 +19,31 @@ gem 'nokogiri', '~> 1.6.1' %p - This Gemfile says a few things. First, it says that bundler should look for gems - declared in the Gemfile at https://rubygems.org by default. If some - of your gems need to be fetched from a private gem server, this default source can be overridden - for those gems. + 이 Gemfile은 몇 가지 이야기를 합니다. 먼저 번들러는 + Gemfile 안에 선언된 gem을 기본 값으로 설정된 + https://rubygems.org에서 찾아야 합니다. 사설 gem 서버에서 + 가져와야 하는 gem이 있다면, 이 기본 소스는 그 gem에서만 덮어 쓸 수 있습니다. %p - Next, you declare a few dependencies: + 다음으로, 몇 가지 의존성을 선언했습니다. %ul - %li on version 4.1.0.rc2 of rails - %li on any version of rack-cache - %li on a version of nokogiri that is >= 1.6.1 but < 1.7.0 + %li rails의 4.1.0.rc2 버전 + %li rack-cache의 아무 버전 + %li nokogiri의 >= 1.6.1지만 < 1.7.0인 버전 %p - After declaring your first set of dependencies, you tell bundler to go get them: + 첫 번째 의존성을 선언한 후에 번들러에게 받도록 해야합니다. :code - $ bundle install # 'bundle' is a shortcut for 'bundle install' + $ bundle install # 'bundle'은 'bundle install'의 단축 명령입니다. %p - Bundler will connect to rubygems.org (and any other sources that you declared), - and find a list of all of the required gems that meet the requirements you specified. Because - all of the gems in your Gemfile have dependencies of their own (and some of - those have their own dependencies), running bundle install on the - Gemfile above will install quite a few gems. + 번들러는 rubygems.org(또는 선언한 다른 소스)에 연결하고 기술한 + 요구사항에 따라 요구된 모든 gem의 목록을 찾을 것입니다. + Gemfile에 있는 모든 gem은 각각의 의존성을 가지고 (또 그 의존성이 + 다른 의존성을 가질 수) 있기 때문입니다. bundle install을 + 실행하면 위의 Gemfile은 꽤 적은 gem을 설치합니다. :code $ bundle install @@ -61,7 +61,7 @@ Installing mime-types 1.25.1 Using bundler 1.6.2 Installing polyglot 0.3.4 - Installing arel 5.0.1.20140414130214 + Installing arel 5.0.1.5.240414130214 Installing hike 1.2.3 Installing mini_portile 0.5.3 Installing multi_json 1.9.3 @@ -87,24 +87,25 @@ Use `bundle show [gemname]` to see where a bundled gem is installed. %p - If any of the needed gems are already installed, Bundler will use them. After installing - any needed gems to your system, bundler writes a snapshot of all of the gems and - versions that it installed to Gemfile.lock. + 필요한 gem이 이미 설치되어 있다면, 번들러는 그것을 사용할 것입니다. 필요한 + gem을 시스템에 설치 후, 번들러는 설치된 모든 gem과 버전 스냅숏을 + Gemfile.lock에 적습니다. %h2#setting-up-your-application-to-use-bundler - Setting Up Your Application to Use Bundler + 번들러를 사용하도록 애플리케이션 설정하기 %p - Bundler makes sure that Ruby can find all of the gems in the Gemfile - (and all of their dependencies). If your app is a Rails 3+ app, your default application - already has the code necessary to invoke bundler. If it is a Rails 2.3 app, please see - Setting up Bundler in Rails 2.3. + 번들러는 루비가 Gemfile 안의 모든 gem(또한 그 gem의 모든 의존성)을 + 찾을 수 있도록 해줍니다. 앱이 레일스 3 이상을 사용하고 있다면, 기본 값을 + 사용하는 애플리케이션은 이미 번들러를 부르는 코드를 가지고 있습니다. 레일스 + 2.3 앱이라면 레일스 2.3에서 번들러 설정하기를 + 보세요. %p - For another kind of application (such as a Sinatra application), you will need to set up - bundler before trying to require any gems. At the top of the first file that your - application loads (for Sinatra, the file that calls require 'sinatra'), put - the following code: + 다른 종류의 애플리케이션(시나트라 같은)이라면 다른 gem을 요청하기 전에 + 번들러를 설정할 필요가 있습니다. 애플리케이션에서 로드하는 첫 번째 파일의 + 제일 위(시나트라라면 require 'sinatra'를 부르는 파일)에 다음 + 코드를 넣으세요. :code # lang: ruby @@ -112,22 +113,23 @@ require 'bundler/setup' %p - This will automatically discover your Gemfile, and make all of the gems in - your Gemfile available to Ruby (in technical terms, it puts the gems "on the - load path"). You can think of it as an adding some extra powers to require - 'rubygems'. + 이는 자동으로 Gemfile을 찾아, Gemfile 안의 모든 + gem을 루비에서 사용 가능하게 할 것입니다.(기술적으로 이야기하면, "로드 + 경로"에 모든 gem을 넣습니다.) require 'rubygems'에 좀 더 힘을 + 실어준다고 생각하셔도 됩니다. %p - Now that your code is available to Ruby, you can require the gems that you need. For - instance, you can require 'sinatra'. If you have a lot of dependencies, you - might want to say "require all of the gems in my Gemfile". To do this, put - the following code immediately following require 'bundler/setup': + 이제 코드를 루비에서 사용 가능하고, 필요한 gem을 요청할 수 있습니다. 예를 + 들어, require 'sinatra'를 할 수 있습니다. 만약 의존성이 아주 + 많다면 "Gemfile에 있는 모든 gem을 require"하고 싶을 수도 + 있습니다. 이렇게 하려면, require 'bundler/setup' 바로 뒤에 밑의 + 코드를 넣으세요. :code # lang: ruby Bundler.require(:default) - For our example Gemfile, this line is exactly equivalent to: + 예제 Gemfile을 기준으로 이 라인은 밑에 구문과 같습니다. :code # lang: ruby @@ -136,9 +138,11 @@ require 'nokogiri' %p - Astute readers will notice that the correct way to require the rack-cache - gem is require 'rack/cache', not require 'rack-cache'. To tell - bundler to use require 'rack/cache', update your Gemfile: + 눈치 빠른 사람은 rack-cache gem을 require하는 바른 방법은 + require 'rack-cache'가 아니라 + require 'rack/cache'라는 걸 눈치 채셨을 겁니다. 번들러가 + require 'rack/cache'를 하게 하려면 Gemfile을 업데이트해야 + 합니다. :code # lang: ruby @@ -149,199 +153,204 @@ gem 'nokogiri', '~> 1.6.1' %p - For such a small Gemfile, we'd advise you to skip - Bundler.require and just require the gems by hand (especially given the - need to put in a :require directive in the Gemfile). For much - larger Gemfiles, using Bundler.require allows you to skip - repeating a large stack of requirements. + 이런 작은 Gemfile에서는 Bundler.require를 하지 + 말고 그냥 손으로 gem을 require하기를 권장합니다.(특히 Gemfile 안에 + :require 지시자를 넣어야 하는 경우는 더욱더) 훨씬 더 큰 + Gemfile의 경우 Bundler.require를 사용하면 많은 + require문을 생략할 수 있습니다. %h2#checking-your-code-into-version-control - Checking Your Code into Version Control + 버전 관리 시스템에 코드를 체크인하기 %p - After developing your application for a while, check in the application together with - the Gemfile and Gemfile.lock snapshot. Now, your repository - has a record of the exact versions of all of the gems that you used the last time you - know for sure that the application worked. Keep in mind that while your - Gemfile lists only three gems (with varying degrees of version strictness), - your application depends on dozens of gems, once you take into consideration all of the - implicit requirements of the gems you depend on. + 한동안 애플리케이션을 개발하면, Gemfile과 + Gemfile.lock 스냅숏을 체크인 하게 됩니다. 이제 저장소는 + 마지막으로 애플리케이션이 실행에 성공했을 때의 모든 gem의 정확한 버전의 + 기록을 가지게 됩니다. 애플리케이션은 십수 개의 gem을 의존하지만 + Gemfile에 (다양한 버전 엄격도를 가진) gem이 3개밖에 없으므로 + 모든 묵시적인 의존성을 고려해야 합니다. %p - This is important: the Gemfile.lock makes your application a single - package of both your own code and the third-party code it ran the last time you know for - sure that everything worked. Specifying exact versions of the third-party code - you depend on in your Gemfile would not provide the same guarantee, because - gems usually declare a range of versions for their dependencies. + 중요한 것은 Gemfile.lock이 애플리케이션을 마지막으로 + 모든 것이 동작했을 때의 직접 만든 코드와 서드 파티 코드를 하나의 패키지로 + 만들어 주는 것입니다. Gemfile에서 의존하는 서드 파티 + 코드의 정확한 버전을 지정하는 것은 아마 같은 보장을 해주지는 못할 것입니다. + 왜냐하면 gem은 보통 의존성을 버전의 범위로 지정하기 때문입니다. %p - The next time you run bundle install on the same machine, bundler will see - that it already has all of the dependencies you need, and skip the installation process. + 다음 bundle install을 같은 기기에서 실행했을 때, 번들러는 이미 + 모든 필요한 의존관계가 있는 것을 확인하고 설치과정을 생략합니다. %p - Do not check in the .bundle directory, or any of the files inside it. Those - files are specific to each particular machine, and are used to persist installation options - between runs of the bundle install command. + .bundle 디렉터리나 그 안의 어떤 파일도 체크인하지 마세요. 이 + 파일은 특정 기기에 한정되고, bundle install 명령을 실행할 때의 + 영속적인 설치 옵션에 사용됩니다. %p - If you have run bundle pack, the gems (although not the git gems) required - by your bundle will be downloaded into vendor/cache. Bundler can run without - connecting to the internet (or the RubyGems server) if all the gems you need are present - in that folder and checked in to your source control. This is an optional - step, and not recommended, due to the increase in size of your source control repository. + bundle pack을 실행했다면, vendor/cache에 gem(git + gem이 아닌 경우)이 다운로드되어야 합니다. 그 폴더에 있는 모든 필요한 gem을 + 버전 관리 시스템에 체크인하면 번들러는 인터넷(이나 루비젬스 서버)에 연결하지 + 않고도 실행할 수 있습니다. 이것은 선택적인 단계이고 + 저장소가 커지기 때문에 권장하지는 않습니다. %h2#sharing-your-application-with-other-developers - Sharing Your Application With Other Developers + 다른 개발자와 애플리케이션 공유하기 %p - When your co-developers (or you on another machine) check out your code, it will come - with the exact versions of all the third-party code your application used on the machine - that you last developed on (in the Gemfile.lock). When **they** run - bundle install, bundler will find the Gemfile.lock and skip - the dependency resolution step. Instead, it will install all of the same gems that you - used on the original machine. + 동료 개발자(나 다른 기기)가 코드를 체크 아웃할 때, 마지막으로 개발 했던 + 기기에서 사용했던 애플리케이션의 모든 서드 파티 코드의 정확한 버전도 + (Gemfile.lock에) 함께 들어있습니다. + **그들이** bundle install을 실행하면, 번들러는 + Gemfile.lock을 찾아 의존성 해결 단계를 생략하는 대신, 원래 + 기기에서 사용했던 gem과 같은 gem을 전부 설치합니다. %p - In other words, you don't have to guess which versions of the dependencies you should - install. In the example we've been using, even though rack-cache declares a - dependency on rack >= 0.4, we know for sure it works with rack - 1.5.2. Even if the Rack team releases rack 1.5.3, bundler will - always install 1.5.2, the exact version of the gem that we know works. This - relieves a large maintenance burden from application developers, because all machines - always run the exact same third-party code. + 다시 이야기하면 의존성의 어느 버전을 설치해야 할지 추측할 필요가 없습니다. + 위의 예제에서 rack-cache가 rack >= 0.4에 의존성이 + 있다고 선언하고 있음에도 불구하고, rack 1.5.2에서 동작하리라 + 확신할 수 있습니다. Rack 팀이 rack 1.5.3을 릴리스 하더라도, + 번들러는 항상 우리가 동작하는 걸 확신할 수 있는 정확한 버전인 + 1.5.2를 설치할 것입니다. 이는 모든 기기에서 정확히 같은 서드 + 파티 코드를 실행하게 하기 때문에 애플리케이션 개발자의 유지 보수 부담을 + 경감합니다. %h2#updating-a-dependency - Updating a Dependency + 의존성 업데이트하기 %p - Of course, at some point, you might want to update the version of a particular - dependency your application relies on. For instance, you might want to update - rails to 4.1.0 final. Importantly, just because you're - updating one dependency, it doesn't mean you want to re-resolve all of your dependencies - and use the latest version of everything. In our example, you only have three - dependencies, but even in this case, updating everything can cause complications. + 물론 어떨 때에는 애플리케이션에 관련된 특정 의존성의 버전만 업데이트 해야 할 + 경우가 있습니다. 예를 들면, rails를 4.1.0으로 + 업데이트 하고 싶을 수 있습니다. 여기서 요점은 하나의 의존성만 업데이트 하는 + 것은, 모든 의존성을 다시 해결해 모두 최종버전으로 올리는 것과는 다르다는 + 것입니다. 우리의 예제에서는 3개의 의존성밖에 없지만, 이 경우에도 모든 것을 + 업데이트하는 것은 부작용이 있을 수 있습니다. %p - To illustrate, the rails 4.1.0.rc2 gem depends on actionpack - 4.1.0.rc2 gem, which depends on rack ~> 1.5.2 (which means >= - 1.5.2 and < 1.6.0). The rack-cache gem depends on - rack >= 0.4. Let's assume that the rails 4.1.0 final gem also - depends on rack ~> 1.5.2, and that since the release of rails - 4.1.0, the Rack team released rack 1.5.3. + 설명하자면, rails 4.1.0.rc2 gem은 actionpack + 4.1.0.rc2 gem에 의존하고 있고 이 gem은 rack ~> 1.5.2에 + 의존 합니다.(>= 1.5.2, < 1.6.0를 의미함) + rack-cache gem은 rack >= 0.4에 의존합니다. + rails 4.1.0 최종 gem도 rack ~> 1.5.2에 의존하고, + rails 4.1.0이 릴리스한 후에, Rack 팀이 rack 1.5.3을 + 릴리스했다고 가정합니다. %p - If we naïvely update all of our gems in order to update Rails, we'll get rack - 1.5.3, which satisfies the requirements of both rails 4.1.0 and - rack-cache. However, we didn't specifically ask to update - rack-cache, which may not be compatible with rack 1.5.3 (for - whatever reason). And while an update from rack 1.5.2 to rack - 1.5.3 probably won't break anything, similar scenarios can happen that involve - much larger jumps. (see [1] below for a larger discussion) + Rails을 업데이트하기 위해, 단순하게 모든 gem을 업데이트 한다고 하면, + rails 4.1.0과 rack-cache의 요구사항을 모두 만족하는 + rack 1.5.3을 얻게 될 것입니다. 하지만 rack 1.5.3과 + 호환성이 없을지도 모르는(이유가 뭐든 간에) rack-cache를 + 업데이트할지 명확하게 묻지 않습니다. 그리고 rack 1.5.2에서 + rack 1.5.3으로 업데이트 해도 아무것도 망가지지 않을 것입니다. + 또한 훨씬 큰 업데이트에서도 비슷한 일이 일어날 수 있습니다.(더 자세한 논의는 아래 + [1]을 보세요) %p - In order to avoid this problem, when you update a gem, bundler will not update a - dependency of that gem if another gem still depends on it. In this example, since - rack-cache still depends on rack, bundler will not update the - rack gem. This ensures that updating rails doesn't - inadvertently break rack-cache. Since rails 4.1.0's dependency - actionpack 4.1.0 remains compatible with rack 1.5.2, bundler - leaves it alone, and rack-cache continues to work even in the face of an - incompatibility with rack 1.5.3. + 이 문제를 피하기 위해, gem을 업데이트할 때, 번들러는 다른 gem이 의존하고 + 있는 gem은 업데이트 하지 않습니다. 이 예제에서는, rack-cache가 + rack에 의존하고 있기 때문에, 번들러는 rack gem을 + 업데이트하지 않습니다. 이렇게 함으로써 rails의 업데이트가 + 무심코 rack-cache를 망가트리지 않게 합니다. rails + 4.1.0이 의존하는 actionpack 4.1.0이 rack + 1.5.2도 호환하고 있기 때문에, 번들러는 그대로 두고, + rack-cache는 rack 1.5.3에서 비호환이 일어나더라도 + 계속 동작하게 됩니다. %p - Since you originally declared a dependency on rails 4.1.0.rc2, if you want - to update to rails 4.1.0, simply update your Gemfile to - gem 'rails', '4.1.0' and run: + 원래 의존성을 rails 4.1.0.rc2로 정의했기 때문에, rails + 4.1.0으로 업데이트를 원한다면, Gemfile을 gem + 'rails', '4.1.0' 업데이트하고 다음을 실행하세요. :code $ bundle install %p - As described above, the bundle install command always does a conservative - update, refusing to update gems (or their dependencies) that you have not explicitly - changed in the Gemfile. This means that if you do not modify - rack-cache in your Gemfile, bundler will treat it **and its - dependencies** (rack) as a single, unmodifiable unit. If rails - 3.0.0 was incompatible with rack-cache, bundler will report a - conflict between your snapshotted dependencies (Gemfile.lock) and your - updated Gemfile. + 위에 설명한 것처럼, bundle install 명령어는 항상 보수적으로 + 업데이트하고, Gemfile에서 명확하게 변경하지 않은 gem과 그 + 의존성의 업데이트를 하지 않습니다. 이 말은 Gemfile에서 + rack-cache를 변경하지 않았다면, 번들러는 그것과 **그것의 + 의존성**(rack)을 하나의 변경할 수 없는 단위로 봅니다. rails + 4.1.0이 rack-cache와 비호환이었다면, 번들러는 스냅숏해둔 + 의존성(Gemfile.lock)과 업데이트된 Gemfile 사이의 + 충돌을 보고하게 됩니다. %p - If you update your Gemfile, and your system already has all of the needed - dependencies, bundler will transparently update the Gemfile.lock when you - boot your application. For instance, if you add mysql to your - Gemfile, and have already installed it in your system, you can boot your - application without running bundle install, and bundler will persist the - "last known good" configuration to the Gemfile.lock snapshot. + Gemfile을 업데이트하고, 시스템이 이미 모든 필요한 의존성이 + 있다면, 번들러는 애플리케이션을 기동할 때 투명하게 Gemfile.lock을 + 업데이트합니다. 예를 들어, 시스템에 이미 설치된, mysql을 + Gemfile에 넣었다면, bundle install을 실행하지 + 않고도 애플리케이션을 기동할 수 있고, 번들러는 Gemfile.lock에 + 스냅숏해둔 "마지막으로 잘 실행되었던" 설정을 지속하게 됩니다. %p - This can come in handy when adding or updating gems with minimal dependencies (database - drivers, wirble, ruby-debug). It will probably fail if you - update gems with significant dependencies (rails), or that a lot of gems - depend on (rack). If a transparent update fails, your application will fail - to boot, and bundler will print out an error instructing you to run bundle - install. + 이는 최소한의 gem(디비 드라이버, wirble, ruby-debug)만 + 추가하거나 업데이트할 때 유용할 수 있습니다. 중대한 + 업데이트(rails)나 많은 gem이 의존하는 gem(rack)의 + 업데이트는 아마 실패할 것입니다. 투명한 업데이트가 실패하면, 애플리케이션은 + 기동에 실패하게 되고, 번들러는 bundle install을 실행하도록 에러 + 화면을 출력합니다. %h2#updating-a-gem-without-modyfying-the-gemfile - Updating a Gem Without Modifying the Gemfile + Gemfile을 수정하지 않고 gem 업데이트하기 %p - Sometimes, you want to update a dependency without modifying the Gemfile. For example, - you might want to update to the latest version of rack-cache. Because you - did not declare a specific version of rack-cache in the - Gemfile, you might want to periodically get the latest version of - rack-cache. To do this, you want to use the bundle update - command: + 가끔은 Gemfile을 수정하지 않고 의존성을 업데이트하고 싶을 수 있습니다. 예를 + 들어, 최신 버전의 rack-cache로 업데이트를 하고 싶다고 합시다. + Gemfile에 rack-cache의 특정 버전을 지정하지 않았기 + 때문에, rack-cache의 최신 버전을 주기적으로 업데이트하고 싶을 + 수 있습니다. 업데이트 하려면, bundle update 명령어를 사용해 + 보세요. :code $ bundle update rack-cache %p - This command will update rack-cache and its dependencies to the latest - version allowed by the Gemfile (in this case, the latest version - available). It will not modify any other dependencies. + 이 명령어는 bundle update와 그 의존성을 Gemfile에서 + 허용하는 최신 버전으로 업데이트 합니다.(이 경우, 가능한 최신 버전) 이는 다른 + 의존성을 변경하지 않습니다. %p - It will, however, update dependencies of other gems if necessary. For instance, if the - latest version of rack-cache specifies a dependency on rack >= - 1.5.2, bundler will update rack to 1.5.2 even though - you have not asked bundler to update rack. If bundler needs to update a - gem that another gem depends on, it will let you know after the update has completed. + 하지만, 필요하다면 다른 gem의 의존성을 업데이트 할 수 있습니다. 예를 들어, + rack-cache의 최신 버전이 의존성으로 rack >= 1.5.3을 + 지정하고 있다면, 번들러는 rack의 업데이트를 요청하지 않았다고 + 하더라도 rack을 1.5.3으로 업데이트합니다. 다른 gem이 + 의존하고 있는 gem을 업데이트할 필요가 있다면, 번들러는 업데이트가 끝난 + 다음에 알려줍니다. %p - If you want to update every gem in the Gemfile to the latest possible versions, run: + Gemfile의 모든 gem을 가능한 최신버전으로 업데이트하고 싶다면, 다음을 + 실행하세요. :code $ bundle update %p - This will resolve dependencies from scratch, ignoring the Gemfile.lock. If - you do this, keep git reset --hard and your test suite in your back pocket. - Resolving all dependencies from scratch can have surprising results, especially if a - number of the third-party packages you depend on have released new versions since you - last did a full update. + 이 명령어는 Gemfile.lock을 무시하고 처음부터 의존성을 + 해결합니다. 이 명령을 실행하기 전에는 반드시 git reset --hard와 + 테스트 스위트를 준비해두세요. 처음부터 모든 의존성을 해결하는 것은 예상치 + 못한 결과가 될 수 있습니다. 특히 마지막으로 업데이트 한 이후 의존하는 여러 + 서드 파티 패키지가 새 버전을 릴리스 했다면 더더욱 그렇습니다. %h2#summary - Summary - %h2 A Simple Bundler Workflow + 요약 + %h2 간단한 번들러 작업 흐름 %ul %li %p - When you first create a Rails application, it already comes with a - Gemfile. For another kind of application (such as Sinatra), run: + 레일스 애플리케이션을 처음 만들 때, 이미 Gemfile이 + 들어있습니다. 시나트라 같은 다른 애플리케이션은 다음을 실행하세요. :code $ bundle init %p - The bundle init command creates a simple Gemfile which you - can edit. + bundle init 명령은 수정할 수 있는 간단한 + Gemfile을 만듭니다. %li %p - Next, add any gems that your application depends on. If you care which version of a - particular gem that you need, be sure to include an appropriate version restriction: + 그런 다음, 애플리케이션이 의존할 gem을 추가하세요. 필요한 특정 gem의 + 버전을 신경써야 한다면, 적절한 버전 제약을 하세요. :code # lang: ruby @@ -353,14 +362,14 @@ %li %p - If you don't have the gems installed in your system yet, run: + 아직 시스템에 설치된 gem이 없다면, 다음을 실행하세요. :code $ bundle install %li %p - To update a gem's version requirements, first modify the Gemfile: + gem의 버전 요구사항을 업데이트하려면, 먼저 Gemfile을 수정하세요. :code # lang: ruby @@ -371,57 +380,57 @@ gem 'rack-bug' %p - and then run: + 그리고 다음을 실행하세요. :code $ bundle install %li %p - If bundle install reports a conflict between your Gemfile - and Gemfile.lock, run: + bundle install이 Gemfile과 + Gemfile.lock이 충돌한다는 보고를 하면 다음을 실행하세요. :code $ bundle update sinatra %p - This will update just the Sinatra gem, as well as any of its dependencies. + 이는 시나트라 gem과 그 의존성만 업데이트합니다. %li %p - To update all of the gems in your Gemfile to the latest possible - versions, run: + Gemfile에 있는 모든 gem을 가능한 최신 버전으로 업데이트 하려면, 다음을 실행하세요. :code $ bundle update %li - Whenever your Gemfile.lock changes, always check it in to version - control. It keeps a history of the exact versions of all third-party code that you - used to successfully run your application. + Gemfile.lock이 변경될 때마다 버전 관리 시스템에 넣으세요. 이는 + 애플리케이션을 성공적으로 실행하는데 필요한 모든 서드 파티 코드의 정확한 + 버전의 이력을 남기게 합니다. %li %p - When deploying your code to a staging or production server, first run your tests (or - boot your local development server), make sure you have checked in your - Gemfile.lock to version control. On the remote server, run: + 스테이징이나 프로덕션 서버에 코드를 배포할 때, 먼저 테스트를 실행하거나 + 지역 개발 서버에서 기동해 보고, 버전 관리 시스템에 + Gemfile.lock이 들어있는지 확인하세요. 원격 서버에서 다음을 + 실행 하세요. :code $ bundle install --deployment %h2#notes - Notes - - %p - [1] For instance, if rails 4.1.0 depended on rack 2.0, that - gem would still satisfy the requirement of rack-cache, which declares - >= 0.4 as a dependency. Of course, you could argue that - rack-cache is silly for depending on open-ended versions, but these - situations exist (extensively) in the wild, and projects often find themselves between a - rock and a hard place when deciding what version to depend on. Constrain the dependency - too much (rack =1.5.1) and you make it hard to use your project in other - compatible projects. Constrain it too little (rack >= 1.0) and a new - release of Rack may break your code. Using dependencies like rack ~> 1.5.2 - and versioning code in a SemVer compliant way mostly solves this problem, but it assumes - universal compliance. Since RubyGems has over 100,000 packages, this assumption simply - doesn't hold in practice. + 주의 + + %p + [1] 예를 들어, rails 4.1.0이 rack 2.0에 의존하고 + 있다고 해봅시다. 이 gem은 여전히 >= 0.4로 정의해둔 + rack-cache의 의존성을 만족합니다. 물론, rack-cache가 + 의존하는 버전 상한이 없는 것에 대해서는 이견이 있을 수 있습니다. 하지만 이런 + 경우는 실제로 (꽤나) 존재하고, 프로젝트는 자주 어느 버전에 의존해야 할지 + 딜레마에 빠집니다. 의존성을 너무 제약하면(rack =1.5.1) 프로젝트를 + 다른 호환 프로젝트에서 사용하기 힘들어집니다. 너무 제약하지 + 않으면(rack >= 1.0) Rack의 새 버전이 릴리스 되었을 때, 코드가 + 망가집니다. rack ~> 1.5.2 같은 의존성을 사용하고 버전 코드로 + 유의적 버전을 사용하면 이런 문제는 대부분 해결 됩니다만, 이는 모두의 협력이 + 필요합니다. 루비젬스에서는 100,000개가 넘는 패키지가 있기 때문에, 이 가정은 + 실제로는 간단하지 않습니다. diff --git a/source/v1.11/rubygems.haml b/source/v1.11/rubygems.haml index b57581a3aa..867881f990 100644 --- a/source/v1.11/rubygems.haml +++ b/source/v1.11/rubygems.haml @@ -1,51 +1,51 @@ -%h2 Using Bundler with Rubygem gemspecs +%h2 번들러를 루비젬스와 함께 사용하기 .contents .bullet .description - If you're creating a gem from scratch, you can use bundler's built in gem skeleton to create a base gem for you to edit. + gem을 처음부터 만든다면, 번들러의 내장 gem 뼈대를 사용해, 수정할 기반 gem을 만들 수 있습니다. .how :code $ bundle gem my_gem .notes - This will create a new directory named my_gem with your new gem skeleton. + 이 명령어는 gem 뼈대를 my_gem 디렉터리에 만듭니다. .bullet .description - If you already have a gem with a gemspec, you can generate a Gemfile for your gem. + gemspec으로 관리되는 gem이 이미 있다면 gem을 위한 Gemfile을 생성할 수 있습니다. :code $ bundle init .notes - Then, add the following to your new Gemfile + 만들었으면, Gemfile에 밑의 내용을 넣으세요. :code # lang: ruby gemspec .bullet .description - Runtime dependencies in your gemspec are treated like base dependencies, and development dependencies are added by default to the group, :development. You can change that group with the :development_group option + gemspec 안의 런타임 의존성은 베이스 의존성으로 간주됩니다. 개발 의존성은 기본치로 :development 그룹 안에 들어가고요. 그룹명은 :development_group 옵션으로 변경할 수 있습니다. :code # lang: ruby gemspec :development_group => :dev .bullet .description - As well, you can point to a specific gemspec using :path. If your gemspec is in /gemspec/path, use + 또 :path를 이용해 특정 gemspec을 지정할 수도 있습니다. gemspec이 /gemspec/path 안에 있다면 이렇게 하세요. :code # lang: ruby gemspec :path => '/gemspec/path' .bullet .description - If you have multiple gemspecs in the same directory, specify which one you'd like to reference using :name + 한 디렉터리에 여러 gemspec을 가지고 있다면, :name을 이용해 어느 것을 참조할지 지정할 수 있습니다. :code # lang: ruby gemspec :name => 'my_awesome_gem' .notes - This will use my_awesome_gem.gemspec + 이렇게 하면 my_awesome_gem.gemspec을 사용하겠죠. .bullet .description - That's it! Use bundler when developing your gem, and otherwise, use gemspecs normally! + 끝입니다! 개발에 번들러를 사용하거나, 평범하게 gemspec을 사용하세요! :code $ gem build my_gem.gemspec diff --git a/source/v1.11/rubymotion.haml b/source/v1.11/rubymotion.haml index 8d3cbdc3d1..9c6beb8857 100644 --- a/source/v1.11/rubymotion.haml +++ b/source/v1.11/rubymotion.haml @@ -1,22 +1,22 @@ -%h2 Using Bundler with RubyMotion +%h2 번들러를 루비모션과 사용하기 .contents .bullet .description - If you don't have a RubyMotion app yet, generate one. + 아직 루비모션 앱이 없다면 만듭니다. :code $ motion create myapp $ cd myapp .bullet .description - You'll need to create a Gemfile. Here we're using bubblewrap. + Gemfile을 만들 필요가 있습니다. bubblewrap을 사용할 때는 이렇게 합니다. :code # lang: ruby gem 'bubble-wrap' .bullet .description - Then, set up your Rakefile to require your bundled gems at compile time. - Add this to the top of the file, right beneath the line `require 'motion/project'` + 그러고 나서 Rakefile을 컴파일할 때 번들된 gem을 require하도록 설정합니다. + require 'motion/project' 바로 밑의 줄에 다음 코드를 추가합니다. :code # lang: ruby require 'bundler' @@ -25,12 +25,12 @@ .bullet .description - Next, install your dependencies: + 다음으로, 의존성을 설치합니다. :code $ bundle install .bullet .description - Now you can just compile your app as normal. + 이제 평범하게 앱을 컴파일 할 수 있습니다. :code $ bundle exec rake diff --git a/source/v1.11/sinatra.haml b/source/v1.11/sinatra.haml index f5d934182d..9f5edddcc4 100644 --- a/source/v1.11/sinatra.haml +++ b/source/v1.11/sinatra.haml @@ -1,16 +1,16 @@ -%h2 Using Bundler with Sinatra +%h2 번들러를 시나트라와 사용하기 .contents .bullet .description - To use bundler with a Sinatra application, you only need to do two things. First, create a Gemfile. + 번들러를 시나트라 애플리케이션과 사용하려면, 두 가지만 하면 됩니다. 먼저 Gemfile을 만듭니다. :code # lang: ruby gem 'sinatra' .bullet .description - Then, set up your config.ru file to load the bundle before it loads your Sinatra app. + 그런 다음, config.ru 파일에서 Sinatra 앱을 로드하기 전에 번들러를 로드합니다. :code # lang: ruby require 'rubygems' @@ -23,6 +23,6 @@ .bullet .description - Start your development server with rackup, and Sinatra will be loaded via Bundler. + rackup으로 개발 서버를 시작하시면, 시나트라는 번들러를 통해 로드됩니다. :code $ bundle exec rackup diff --git a/source/v1.11/updating_gems.haml b/source/v1.11/updating_gems.haml index 37fc25ead7..408bc86ce7 100644 --- a/source/v1.11/updating_gems.haml +++ b/source/v1.11/updating_gems.haml @@ -1,116 +1,123 @@ -%h2 Updating Gems +%h2 gem 업데이트하기 .contents .bullet .description %h3#updating-a-dependency - Updating a Dependency + 의존성 업데이트하기 %p.description - Of course, at some point, you might want to update the version of a particular - dependency your application relies on. For instance, you might want to update - rails to 3.0.0 final. Importantly, just because you're - updating one dependency, it doesn't mean you want to re-resolve all of your dependencies - and use the latest version of everything. In our example, you only have three - dependencies, but even in this case, updating everything can cause complications. + 물론 어떤 경우에는 애플리케이션에서 사용하는 특정 의존성만 업데이트하길 + 원할 수 있습니다. 예를 들어, rails를 3.0.0 + 최종으로 업데이트한다고 합시다. 중요한 것은 하나의 의존성을 업데이트 해야 + 하기 때문에 모든 의존성을 업데이트할 필요는 없다는 점입니다. 예제의 + 의존성은 3개뿐이지만, 이 경우에도 모든 것을 업데이트하는 것은 귀찮은 + 문제의 원인이 될 수 있습니다. %p.description - To illustrate, the rails 3.0.0.rc gem depends on actionpack - 3.0.0.rc gem, which depends on rack ~> 1.2.1 (which means >= - 1.2.1 and < 1.3.0). The rack-cache gem depends on - rack >= 0.4. Let's assume that the rails 3.0.0 final gem also - depends on rack ~> 1.2.1, and that since the release of rails - 3.0.0, the Rack team released rack 1.2.2. + 설명하자면 rails 3.0.0.rc gem은 actionpack + 3.0.0.rc gem에 의존하고 있고, 이는 다시 rack ~> 1.2.1에 + 의존합니다.(>= 1.2.1과 < 1.3.0을 동시에 만족) + rack-cache gem은 rack >= 0.4에 의존합니다. + rails 3.0.0 최종 gem이 rack ~> 1.2.1에도 의존하고 + rails 3.0.0 릴리스 이후에 Rack 팀이 rack 1.2.2를 + 릴리스했다고 가정해 봅시다. %p.description - If we naïvely update all of our gems in order to update Rails, we'll get rack - 1.2.2, which satisfies the requirements of both rails 3.0.0 and - rack-cache. However, we didn't specifically ask to update - rack-cache, which may not be compatible with rack 1.2.2 (for - whatever reason). And while an update from rack 1.2.1 to rack - 1.2.2 probably won't break anything, similar scenarios can happen that involve - much larger jumps. (see [1] below for a larger discussion) + 레일스를 업데이트하기 위해 단순하게 모든 gem을 업데이트한다고 하면, + rails 3.0.0과 rack-cache의 요구사항을 모두 + 만족하는 rack 1.2.2를 얻게될 것입니다. 하지만 + rack 1.2.2와 비호환일 수도 있는 rack-cache의 + 업데이트는 요청한 적이 없습니다.(이유가 무엇이든 간에) 그리고 rack + 1.2.1에서 rack 1.2.2로 업데이트 하면 아마 아무것도 망가뜨리지 + 않을 것입니다만, 훨씬 큰 변경에서는 비슷한 시나리오가 생길 수 + 있습니다.(더 자세한 논의는 밑의 [1]을 참조하세요.) %p.description - In order to avoid this problem, when you update a gem, bundler will not update a - dependency of that gem if another gem still depends on it. In this example, since - rack-cache still depends on rack, bundler will not update the - rack gem. This ensures that updating rails doesn't - inadvertently break rack-cache. Since rails 3.0.0's dependency - actionpack 3.0.0 remains compatible with rack 1.2.1, bundler - leaves it alone, and rack-cache continues to work even in the face of an - incompatibility with rack 1.2.2. + 이 문제를 피하기 위해, gem을 업데이트할 때 번들러는 다른 gem이 의존하고 + 있는 gem의 의존성은 업데이트하지 않습니다. 이 예제의 + rack-cache가 여전히 rack에 의존하고 있기 때문에 + 번들러는 rack gem을 업데이트하지 않습니다. 이는 + rails의 업데이트가 실수로 rack-cache를 망가트리지 + 않도록 보증해 줍니다. rails 3.0.0의 의존성인 actionpack + 3.0.0이 rack 1.2.1과 호환하기 때문에, 번들러는 그대로 + 두고, rack-cache는 rack 1.2.2와 비호환임에도 + 계속 동작하게 됩니다. %p.description - Since you originally declared a dependency on rails 3.0.0.rc, if you want - to update to rails 3.0.0, simply update your Gemfile to - gem 'rails', '3.0.0' and run: + 원래의 의존성을 rails 3.0.0.rc로 정의했기 때문에, + rails 3.0.0으로 업데이트하려 한다면, Gemfile을 + gem 'rails', '3.0.0'으로 업데이트하고 다음을 실행하면 됩니다. :code $ bundle install %p.description - As described above, the bundle install command always does a conservative - update, refusing to update gems (or their dependencies) that you have not explicitly - changed in the Gemfile. This means that if you do not modify - rack-cache in your Gemfile, bundler will treat it **and its - dependencies** (rack) as a single, unmodifiable unit. If rails - 3.0.0 was incompatible with rack-cache, bundler will report a - conflict between your snapshotted dependencies (Gemfile.lock) and your - updated Gemfile. + 위에서 설명한 것처럼, bundle install 명령은 항상 보수적으로 + 업데이트를 하고, Gemfile에서 명시적으로 변경하지 않은 + gem(또는 그 의존성)을 업데이트하지 않습니다. 이 말은 Gemfile에서 + rack-cache를 변경하지 않았다면 번들러는 그것**과 그 + 의존성**(rack)을 하나의 변경할 수 없는 단위로 취급합니다. + rails 3.0.0이 rack-cache와 비호환이라면 번들러는 + 의존성 스냅숏(Gemfile.lock)과 업데이트된 Gemfile + 사이의 충돌을 보고해 줍니다. %p.description - If you update your Gemfile, and your system already has all of the needed - dependencies, bundler will transparently update the Gemfile.lock when you - boot your application. For instance, if you add mysql to your - Gemfile, and have already installed it in your system, you can boot your - application without running bundle install, and bundler will persist the - "last known good" configuration to the Gemfile.lock snapshot. + Gemfile을 업데이트할 때 시스템이 모든 필요한 의존성을 가지고 + 있다면, 번들러는 애플리케이션을 시동할 때 Gemfile.lock을 + 투명하게 업데이트해 줍니다. 예를 들어, Gemfile에 + 시스템에는 이미 설치되어 있는 mysql을 추가한 경우, + bundle install을 실행하지 않고도 애플리케이션을 시동할 수 + 있고, 번들러는 "마지막으로 성공한" Gemfile.lock 스냅숏 설정을 + 지속합니다. %p.description - This can come in handy when adding or updating gems with minimal dependencies (database - drivers, wirble, ruby-debug). It will probably fail if you - update gems with significant dependencies (rails), or that a lot of gems - depend on (rack). If a transparent update fails, your application will fail - to boot, and bundler will print out an error instructing you to run bundle - install. + 이것은 gem을 최소한의 의존성으로 추가하거나 업데이트할 때 + 유용합니다.(데이터베이스 드라이버, wirble, + ruby-debug) 이는 중요한 의존성(rails)이 있는 gem을 + 업데이트 하거나 gem에 의존성이 많을 경우(rack) 아마도 실패하게 + 될 것입니다. 투명하게 업데이트가 실패한 경우, 애플리케이션은 기동에 + 실패하게 되고 bundle install을 실행할 때 번들러는 에러 메시지를 + 출력할 것입니다. .bullet .description %h3#updating-a-gem-without-modifying-the-gemfile - Updating a Gem Without Modifying the Gemfile + Gemfile을 수정하지 않고 gem 업데이트하기 %p - Sometimes, you want to update a dependency without modifying the Gemfile. For example, - you might want to update to the latest version of rack-cache. Because you - did not declare a specific version of rack-cache in the - Gemfile, you might want to periodically get the latest version of - rack-cache. To do this, you want to use the bundle update - command: + 가끔 Gemfile을 수정하지 않고 의존성을 업데이트하고 싶을 때가 있습니다. + 예를 들어 rack-cache를 최신 버전으로 업데이트하고 싶다고 + 하면 Gemfile에 rack-cache의 버전을 지정하지 + 않았기 때문에, 아마 정기적으로 rack-cache의 최신 버전을 + 얻길 원할 것입니다. 이렇게 하려면 bundle update 명령을 + 사용하시면 됩니다. :code $ bundle update rack-cache %p - This command will update rack-cache and its dependencies to the latest - version allowed by the Gemfile (in this case, the latest version - available). It will not modify any other dependencies. + 이 명령어는 rack-cache와 그 의존성을 Gemfile에서 + 허용하는 최신 버전으로 업데이트합니다.(이 경우, 최신 버전 사용가능) 이 + 명령은 다른 의존성을 수정하지 않습니다. %p - It will, however, update dependencies of other gems if necessary. For instance, if the - latest version of rack-cache specifies a dependency on rack >= - 1.2.2, bundler will update rack to 1.2.2 even though - you have not asked bundler to update rack. If bundler needs to update a - gem that another gem depends on, it will let you know after the update has completed. + 하지만 필요한 경우에는 다른 gem의 의존성을 업데이트할 수 있습니다. 예를 + 들어 rack-cache의 최신 버전이 rack >= 1.2.2을 + 의존성으로 지정하고 있다면, 번들러는 당신이 rack의 + 업데이트를 시킨 적이 없더라도 rack을 1.2.2로 + 업데이트할 것입니다. 번들러가 다른 gem에 의존하는 gem을 업데이트 했다면 + 업데이트가 끝난 후 알 수 있습니다. %p - If you want to update every gem in the Gemfile to the latest possible versions, run: + 모든 gem의 가능한 최신 버전으로 업데이트하고 싶다면, 다음 명령을 + 실행하세요. :code $ bundle update %p - This will resolve dependencies from scratch, ignoring the Gemfile.lock. If - you do this, keep git reset --hard and your test suite in your back pocket. - Resolving all dependencies from scratch can have surprising results, especially if a - number of the third-party packages you depend on have released new versions since you - last did a full update. + 이 명령은 Gemfile.lock을 무시하고 의존성을 다시 해결합니다. + 이렇게 하려면, git reset --hard와 테스트 스위트를 준비해 + 두세요. 모든 의존성을 해결 하는 것은 놀라운 결과를 얻을 수 있습니다. 특히 + 마지막으로 업데이트한 후에 많은 서드 파티 패키지가 새 버전을 발표했다면 + 더더욱 그렇습니다.