Giters

depfu / feedback

🤔 Question, bugs and feedback for Depfu

Home Page:https://depfu.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bundler cannot parse Gemfile when gem version given as File.read('.version')

andreaswachowski opened this issue · comments

commented

We have a Gemfile where the version for some gems is specified in a shared file, like so:

gem 'name-of-gem', File.read('.version').strip

This works fine in Gitlab CI and in production. But Depfu complains with

Bundler Error: [!] There was an error parsing Gemfile: No such file or directory @ rb_sysopen - .version. Bundler cannot continue.

The same happens when we use one of the following variants (except the error message refers to a different file name, e.g. /tmp/d20230315-1-ipl6vp/.version when we specify the absolute name):

  • File.read("./.version")
  • File.read("{__dir__}/.version")
  • File.read(File.join(__dir__), '.version'))

It would be great if we could get this to work!

Edit: The file .version includes, of course, just a version specification like 1.2.3.

commented

HI @andreaswachowski - This is really hard for us to get working because for security reasons we don't actually run the ruby code in the Gemfile. People use all kinds of weird things in Gemfiles and most of them don't work in Depfu.

I know why you want to do this, but I personally would consider it bad practice. Making the dependency declaration executable code was (IMHO) the biggest mistake the Bundler team made.

I know this leads to a bit more work when updating the set of dependencies that use that declaraction, but that's what Depfu is for. If it is a well known set of dependencies that always update in sync, Depfu even recognises that - If it is a set of gems where Depfu doesn't do that yet, please let us know.

I know this isn't the answer you were looking for but my advice would always to keep Gemfiles as dumb as possible.

commented

The answer is perfectly fine, many thanks! That certainly clarifies the behaviour, and I can follow the reasoning. The security aspect is valid. I will close this issue.

(The use case described applies only to a few internal Gems which we develop ourselves and which we need to control manually, so it's a bit of an edge case anyway.)