00:00:00.060
The next speaker is Colby Swandale.
00:00:05.509
This is Mr. Colby Swandale, and the title of his talk is 'Bundler 2.'
00:00:19.740
Good afternoon, everyone. Thank you for coming to my talk.
00:00:25.560
I wanted to share some progress that the Bundler core team has been making over the past year and discuss the future of Bundler with the upcoming release.
00:00:30.599
My name is Colby, and I am from Melbourne, Australia. I'm currently serving on the Bundler core team.
00:00:35.670
I'm also the newest member, having joined earlier this year. I work at a company in Melbourne called Marketplace.
00:00:42.989
We're a tailor-made eCommerce platform for businesses, and I would not be here today without their support. So, thank you very much for letting me be here.
00:00:50.309
Before diving into Bundler 2, I'd like to highlight some new features that have been added to Bundler over the past 12 months, both from the core team and contributors.
00:01:03.570
One new command is 'bundler doctor,' which helps diagnose problems with gem installations.
00:01:08.580
We have plans to extend this feature further, and currently, there is a pull request in progress where Bundler Doctor will check the file permissions of your installed gems and report any possible issues.
00:01:14.159
Another new command is 'bundle add,' which allows you to add a gem to your Gemfile without having to edit the Gemfile directly.
00:01:24.990
For example, I have a Gemfile here that lists only Rack. By using 'bundle add,' I can insert a gem, such as 'rspec,' into my Gemfile, and then Bundler will automatically install 'rspec' for me.
00:01:39.090
Bundler will append the given gem to the Gemfile accordingly.
00:01:44.189
Additionally, 'bundle add' will allow you to specify options such as version constraints, sources, and groups.
00:02:00.149
Another significant feature that has been introduced recently is Bundler plugins. These allow you to extend the behavior of Bundler without making changes to the source code.
00:02:16.560
There are two types of plugins: command plugins and hook plugins. Command plugins let you add your own commands to Bundler, while hook plugins allow you to hook into Bundler events, such as when installing gems.
00:02:27.300
Here's a quick example of a command plugin. A plugin is similar to a regular gem but includes a special file called 'plugin.rb,' where you define the Bundler command you wish to add. In this example, we create a new class that inherits from the Bundler API to close a new command and implement a command action method. For this example, we would just print out 'Hello, World!' You can invoke this command from Bundler.
00:02:48.600
Hook plugins allow you to add behavior to the Bundler lifecycle, such as during gem installations. Using the Bundler plugin API, you can set up a new hook for the 'before_install' event and define additional behavior.
00:03:03.300
When plugins are installed via the plugin command, they connect to the specified events and can perform their defined actions.
00:03:18.660
Plugins can also be specified in the Gemfile using the 'plugin' method.
00:03:26.580
Bundler plugins are a relatively new feature, and there is still plenty of work to be done. If you're interested in contributing to the Bundler project, I recommend checking out the documentation.
00:03:32.980
We’ve also been working on fixing a variety of issues in Bundler, such as addressing file permission problems and resolving various bugs. We've been improving error messages as well, adding messages that provide more context about issues that occur. Our goal is to make these messages more user-friendly and easier to understand.
00:04:07.720
Thanks to the contributions from both the core team and contributors—some of whom are present here—Bundler is undergoing significant optimizations. This includes enhancements in the resolver, resulting in faster resolution times for gem installations.
00:04:15.100
Although we have made progress, we still have ideas for improving resolver speed and overall performance.
00:04:28.270
In the near future, the core team plans to release the next version of Bundler, 1.16. This will likely be the last feature release for Bundler 1. I recommend upgrading to it before we transition to Bundler 2.
00:04:48.910
Bundler 1.0 was originally released back in August 2010, and since then, the Bundler core team has made numerous improvements to user experience by introducing new features while refining existing functionality.
00:05:03.820
However, some decisions made back then are no longer relevant, and technical debt has gradually crept into the codebase.
00:05:20.410
With the upcoming major release of Bundler, we will introduce several changes aimed at addressing these issues.
00:05:30.610
Let’s take a look at what is being removed, added, and changed in Bundler 2.
00:05:42.620
Many removals are happening in Bundler 2. As I mentioned, Bundler will focus mainly on fixing issues and removing features that have become obsolete.
00:06:00.300
One major change is the dropping of support for older Ruby versions. Bundler 1 currently supports Ruby 1.8.7, but with Bundler 2, we will remove support for all Ruby versions that are no longer maintained by the Ruby core team.
00:06:14.000
This includes all major Ruby versions up to 2.3.
00:06:25.900
Another thing we are removing from Bundler is the integrations for Capistrano and other deployment tools, as there are already libraries available that provide this functionality.
00:06:43.000
Furthermore, we will be removing Gemfile shortcuts for lesser-known platforms that are no longer in existence, as they only route requests to rubygems.org.
00:07:03.490
With Bundler 2, we’ll rely on existing source helpers instead of maintain shortcuts that are now obsolete.
00:07:19.990
For example, if you've generated a new Bundler Gemfile, you may have noticed a snippet at the top to pull dependencies from GitHub using HTTP.
00:07:35.750
In Bundler 1, using the GitHub helper directly pulls from GitHub over plain HTTP. You can continue using this helper in Bundler 2, but all other services will be removed.
00:07:52.450
Lastly, we've removed the ability to specify a list of gems that come from GitHub directly; users are encouraged to use the source block instead.
00:08:08.811
The 'bundle show' command, which is currently overloaded with three different behaviors, will be replaced by 'bundle info' and 'bundle list.'
00:08:21.490
In Bundler 1, if you run 'bundle show' without arguments, it lists all gems with their versions, but this can be confusing.
00:08:37.380
We are moving forward with 'bundle list' to list your gems and 'bundle info' to provide detailed information about a specific gem.
00:08:51.420
Bundler viz, a tool for graphing dependencies, will also be removed from the source code and will instead be transformed into its own gem that will utilize the Bundler plugin API.
00:09:07.420
Although this gem is not currently developed, it will become available with future Bundler 2 releases.
00:09:21.000
The command 'bundle console,' which starts an IRB session with your gems loaded, will also be removed from the core.
00:09:29.720
There are currently no replacement plans, but it could be converted into a Bundler plugin.
00:09:38.390
Additionally, Bundler 1 currently persists certain options when you run 'bundle install,' but we will be removing this feature in Bundler 2.
00:09:53.900
Users will need to specify arguments each time they install. This change aims to reduce confusion for new users.
00:10:08.120
We will also no longer support certain command line options which will now be configured through the Bundler config.
00:10:15.390
This applies particularly for settings used in CI or production environments, as we found these to often confuse users.
00:10:31.950
We're removing the implementation of 'bundler cache' environment variables and will refocus on 'bundler package,' which is an efficient way to package gems.
00:10:48.819
The Bundler package will now be considered an improved implementation, and for those unfamiliar, it allows you to export gems into a folder for deployment.
00:11:05.190
Additionally, Bundler is being built with a more efficient global gem extension feature, which allows for switching between Ruby versions without reinstalling gems.
00:11:20.380
The specific platform feature will also be introduced, enabling Bundler to consider the platform of your machine during the resolve process.
00:11:36.700
This feature accounts for the operating system, version, and architecture, ensuring gems are resolved correctly for the user's environment.
00:11:52.150
In Bundler 1, if you run 'bundle install' with gems that contain extensions, it typically resolves using a generic Ruby platform.
00:12:15.690
With Bundler 2, it will match the platform specifics, resolving to the best available gem for that environment.
00:12:30.880
This improvement allows for smoother operating across different machines without the need to constantly compile extensions.
00:12:48.840
In terms of changes in Bundler 2, the default command when you issue a command without arguments will change from aliasing 'bundle install' to just displaying available commands.
00:13:01.799
Users will have to use the 'update' command with the '-all' flag to update all gems if they choose to do so.
00:13:18.090
Overall, Bundler 2 is a significant upgrade. Further details will be rolled out in our detailed RFC, which I have set up on GitHub as Bundler RFCs, pull number six.
00:13:35.990
We want the transition to Bundler 2 to be as seamless as possible, and we appreciate your help in testing beta versions.
00:13:53.690
People testing these beta versions will help us identify scenarios we may not have considered as we develop new features.
00:14:11.490
For context, nearly everyone in this room has contributed to the code that will appear in Bundler 2.
00:14:28.480
Bundler 2 features include flags to enable or disable specific functionality.
00:14:44.299
Feature flags will enable specific functionalities, while errors will be printed to standard error instead of standard output.
00:15:01.560
In short, all feature flags will be set to true by default. If you prefer, you can opt out of using these feature flags, but you'll need to wait for us to release our preview version.
00:15:19.470
It's important to note that Bundler is not backward compatible with Bundler 1.
00:15:38.470
Once you use Bundler 2, you cannot revert to Bundler 1. So make sure to coordinate with your team for a smooth transition.
00:15:55.940
In wrapping up this presentation, I'd like to mention future plans. We aim to make major releases more frequently, similar to the Ruby release schedule.
00:16:14.350
This will allow us to drop support for obsolete Ruby versions while implementing significant improvements that have been long awaited.
00:16:36.720
Bundler will also start shipping with Ruby, beginning with Ruby 2.5, which we are quite excited about.
00:16:50.370
If you'd like to contact me, you can find me on Twitter @0xColby or via my GitHub where I have additional resources available.
00:17:09.090
We also have a Slack channel welcoming anyone who wants to join; you can receive an invite at slack.bundler.io.
00:17:25.570
Feel free to ask questions or raise issues on GitHub about Bundler. We have extensive documentation available for further assistance.
00:17:39.200
If you're interested in contributing, our GitHub repository has some of the best guidelines on how to get involved.
00:17:55.280
We welcome contributions from everyone, regardless of experience, and are happy to help newcomers.
00:18:08.340
Another way to support the Bundler project is through funding development via Ruby Together, which helps sustain work on the Ruby ecosystem.
00:18:24.440
Thank you for your time.
00:18:44.720
Are there any questions?
00:18:54.880
I may have missed this, but I noticed some slides used the Bundler command and others referred to 'bundle.' Is there a difference?
00:19:05.950
'Bundle' is the actual command, while 'bundler' is just a shorthand for referring to it; it's a personal preference.
00:19:13.490
For the Ruby platform, can any platform that implements Ruby work? You mentioned it's a required field.
00:19:22.060
Yes, the platform is a required field for any gem, which by default is set to the Ruby platform.
00:19:30.740
For JRuby, do you have to specify that it's a Java platform?
00:19:42.310
Unless there are special Java dependencies, a gem file intended for MRI Ruby can generally run on JRuby without problems.
00:19:56.140
This transition is designed to be seamless.
00:20:05.640
What Ruby version will Bundler ship with, especially alongside Ruby 2.5?
00:20:13.500
The upcoming release will be Bundler 1.15, but the pre-release version of Bundler 2 is coming soon.
00:20:22.220
We anticipate that Bundler 2 will significantly bridge the gap with Ruby 2.5.
00:20:31.880
One last concern is the potential changes to the Gemfile, particularly regarding uppercase naming conventions.
00:20:45.970
Nothing substantial is changing. Bundler will still support both the capitalized Gemfile and the lowercased gems.rb.
00:20:59.290
However, if both are present, Bundler will prefer gems.rb.
00:21:05.890
There are no plans to deprecate or remove either file type.
00:21:15.660
Thank you for clarifying that.
00:21:26.270
If everyone starts using Bundler 2, how will that affect backward compatibility?
00:21:38.300
Bundler 2 will understand Bundler 1 lock files, but the reverse will not be true.
00:21:51.920
So, deploying to a platform like Heroku may need some caution.
00:22:03.480
If deploying with Bundler 2, it can prompt unintended changes to the lock file.
00:22:16.250
We'll need to keep these nuances in mind for seamless transitions.
00:22:35.810
Thank you for sharing your thoughts.
00:22:47.100
Are there any further questions before we conclude?
00:22:58.920
I commend you on your decisions regarding earlier Ruby version support.
00:23:11.590
The core team has not faced much opposition regarding this removal.
00:23:23.240
Also, Bundler will keep supporting legacy versions as needed.
00:23:35.390
This adjustment aims to reduce code complexity and technical debt.
00:23:46.320
Thank you so much for your attention.