formula_creator: commented examples for ruby dependencies #18190
Conversation
| # system "bundle", "config", "set", "without", "development", "test" | ||
| # system "bundle", "install" | ||
|
|
||
| # Install dependencies declared as resources |
There was a problem hiding this comment.
How often is this the case for new Ruby formulae? Seems like a Gemfile.lock is pretty standard now?
There was a problem hiding this comment.
None in last 5 new Ruby formulae, but yes in last 10:
- pedump 0.6.10 (new formula) homebrew-core#173274 - Gemfile.lock
- ronn-ng 0.10.1 (new formula) homebrew-core#172077 - via
gem install - deadfinder 1.3.4 (new formula) homebrew-core#161231 - Gemfile.lock
- sugarjar 1.0.1 (new formula) homebrew-core#157910 - Gemfile.lock
- haiti 1.5.0 (new formula) homebrew-core#152307 - haiti: use
bundlerinstead of resources homebrew-core#161343 - wpscan 3.8.24 (new formula) homebrew-core#136553 - resources, but dropped due to license
- dexter 0.4.3 (new formula) homebrew-core#126915 - resources
- opal 1.7.3 (new formula) homebrew-core#126482 - via
gem install
May also need to decide if gem install should be valid way of installing dependencies, or we should require --ignore-dependencies.
There was a problem hiding this comment.
- ronn-ng 0.10.1 (new formula) homebrew-core#172077 - via
gem install
This had a Gemfile.lock, I wonder why we didn't use it. Feels like it should be an audit failure if it has one and we don't use it.
gem install seems like it could be valid, then, if we need version pinning although personally I'd tend towards just saying we always use bundle install (given all of these have Gemfiles)
| # system "gem", "install", r.cached_download, "--ignore-dependencies", | ||
| # "--no-document", "--install-dir", libexec | ||
| # end | ||
|
|
||
| system "gem", "build", "\#{name}.gemspec" | ||
| system "gem", "install", "\#{name}-\#{@version}.gem" |
There was a problem hiding this comment.
| system "gem", "install", "\#{name}-\#{@version}.gem" | |
| system "gem", "install", "--ignore-dependencies", "\#{name}-\#{@version}.gem" |
There was a problem hiding this comment.
This feels weird. Why is it needed?
There was a problem hiding this comment.
In order to make sure one of the previous commands (bundle install or resources) handles the dependencies.
Otherwise, for formulae with dependencies but without Gemfile.lock, this will install the latest gems and makes it less reproducible/checksummed.
It is in our documentation:
Line 248 in 638a3dc
There was a problem hiding this comment.
Otherwise, for formulae with dependencies but without
Gemfile.lock, this will install the latest gems and makes it less reproducible/checksummed.
This is true but I wonder how much of a problem this is for us in reality, particularly if we just move to using bundle install entirely instead (which I trust to handle the edge-cases here more than gem install).
I think the ideal outcome here (but not blocking this PR on that) would be to run bundle install and actually include the Gemfile.lock in e.g. the bottle/manifest/tab/prefix/etc.
We could take a similar approach for other packaging systems, too, and it avoids all the shit manual work required with resources.
|
Close for now as I need to think about this a little more and compare different installation commands (perhaps comparing different language approaches to see if there is a better middle-ground). |
brew stylewith your changes locally?brew typecheckwith your changes locally?brew testswith your changes locally?Also update documentation as original command is deprecated (https://bundler.io/v2.5/man/bundle-install.1.html#OPTIONS).