00:00:12
This talk is about how Bundler works. How does Bundler work? This is an interesting question, and we'll talk about it for a while.
00:00:22
The talk is kind of a brief, hopefully brief, history of dependency management in Ruby.
00:00:33
We will also discuss how libraries and shared code work.
00:00:40
This includes both how it worked in the past and how it works now because the current system is directly a result of past implementations.
00:00:52
Before we get started, let me introduce myself. My name is André Arko, and I am involved in many internet-related things.
00:01:06
As my day job, I work at Cloud City Development, doing Ruby on Rails, web, and Ember consulting. We focus on web and mobile development.
00:01:18
I primarily do architectural consulting and senior developer training. If that's something your company needs, feel free to talk to me later.
00:01:31
Additionally, I founded a non-profit called Ruby Together. It's somewhat like NPM but without the venture capital.
00:01:47
Ruby Together acts as a trade association that collects funds from companies and individuals who use Ruby, Bundler, Rubygems, and other shared infrastructure. We use those funds to pay developers to support this public infrastructure.
00:02:04
As part of my work, I lead the Bundler team.
00:02:10
I've been involved with Bundler since before version 1.0 was released and have been the team lead for the past four years.
00:02:21
Using Ruby code written by other developers nowadays is actually very easy.
00:02:31
You simply add a line to your Gemfile, say 'gem foo', go to your terminal, and run 'bundle install'. Then you can start using it.
00:02:40
It’s that simple! However, I've noticed that many users who find Bundler amazing often don't understand what just happened during the installation process.
00:02:57
The output printed by Bundler during installation can be unclear. It seems like something got downloaded and installed, but it’s not crystal clear what or where it all occurred.
00:03:14
So, how does just adding a line in your Gemfile enable you to use someone else's code?
00:03:21
To explain this, we need to look back at a little history in Ruby regarding code sharing.
00:03:30
This history includes the introduction of the 'require' method, which came with the first version of Ruby in 1994, followed by 'setup.rb' in 2000, then 'rubygems' in 2003, and finally 'bundler' in 2009, which is what we still use today.
00:03:54
The 'require' method has been integral since the very first version of Ruby, allowing one to use code from different files.
00:04:07
This is essentially like inserting that code directly into your application.
00:04:20
You could implement a simple version of 'require' using just a one-liner.
00:04:32
For example, you could read the file into memory, pass the string to 'eval', and Ruby would execute it as if you’d written it in the file.
00:04:46
However, there are practical issues with this approach.
00:04:57
If you ran the same piece of code multiple times, you'd encounter problems with constants being redefined.
00:05:10
To address this, you could track required files in an array.
00:05:15
If a file had already been required, you would avoid requiring it again.
00:05:24
This is similar to what Ruby does with a global variable called 'loaded_features', which keeps track of all previously required files.
00:05:35
An additional problem arises, however, because this method requires absolute paths for files.
00:05:45
The easiest solution is to treat all requires as relative to the directory from which the Ruby program started.
00:06:02
However, this still causes issues for requiring files from different directories.
00:06:10
If you have a library in a separate folder, writing relative paths can become quite tedious.
00:06:25
Thus, we can create a 'load path' array.
00:06:31
This array would list directories where Ruby should look for files, allowing us to use relative paths.
00:06:43
In fact, this is what Ruby does—it uses a global 'load_path' variable to search directories for the appropriate files.
00:06:57
The 'load_path' and 'loaded_features' can be combined for effective functionality.
00:07:06
However, managing these paths manually can become burdensome.
00:07:14
For many years, this was the norm. Developers would simply add paths to the load path or modify it through scripts.
00:07:26
Despite this being a working solution, it became tedious to organize and manage shared libraries manually.
00:07:43
Thus, the introduction of 'setup.rb' in 2000 aimed to simplify the installation of shared Ruby code.
00:08:01
Some of the issues with it included the lack of versioning and an inability to uninstall libraries, which led to a cumbersome experience.
00:08:16
As a result, managing dependencies often became a trial-and-error process. If a new version of a library was released, you had to manually track the installation and its versioning.
00:08:35
This led developers to regularly encounter difficulties when upgrading libraries or managing dependencies.
00:08:46
In 2003, RubyGems emerged to resolve many of these issues, allowing easy installation, uninstallation, and versioning of libraries.
00:09:02
Each library was now separated into directories, making it transparent which libraries were installed and simplifying the upgrade process.
00:09:21
RubyGems also introduced the 'gem' method, which facilitated the management of dependencies.
00:09:32
However, problems persisted when multiple applications used RubyGems.
00:09:41
It became challenging to coordinate dependencies across different applications.
00:09:55
Changes by one developer could lead to breaks in another developer’s setup, spawning a cycle of manual dependency management.
00:10:11
To remedy these challenges, tools such as Rails' 'config.gem' were introduced, but they weren't foolproof.
00:10:23
If a newer version of a gem was installed after another developer's installation, it could lead to inconsistencies.
00:10:35
This created a situation where dependency management was often a hands-on task.
00:10:48
Ultimately, these difficulties highlighted the need for a more reliable solution to manage Ruby dependencies.
00:11:02
As the demand for a robust method increased, Bundler was born to help manage dependencies seamlessly.
00:11:19
With Bundler, dependency resolution is performed ahead of time, allowing all versions of gems that will work together to be identified before an application runs.
00:11:34
This drastically reduces the chances of encountering activation errors in applications.
00:11:49
The core functionality lies in the ability to specify dependencies in a 'Gemfile' and then perform a bundling operation.
00:12:04
Through the use of the 'Gemfile.lock', Bundler allows for consistency across environments.
00:12:17
Regardless of when or how a developer installs the gems, the lock file ensures identical versions across machines.
00:12:30
Since activating the right versions of dependencies is critical, Bundler has been built to manage this efficiently.
00:12:46
When running 'bundle install', Bundler installs the specific versions listed in the lock file.
00:13:01
And when using 'bundle exec', it loads only those versions, ensuring that activation errors are minimized.
00:13:13
To sum up, Bundler significantly streamlines the process of managing gem installations and dependencies.
00:13:27
If you utilize Bundler and are interested in contributing or learning more, many resources are available.
00:13:43
Additionally, you can always find us on social media or through our website, where we provide updates and track the progress of Bundler.
00:14:00
Finally, if you are interested, we have stickers for Bundler and Ruby Together, so feel free to find me after the talk!
00:14:18
That is all I have for today.
00:14:38
Thank you!
