Closed andreaswachowski closed 1 year ago
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.
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.)
We have a Gemfile where the version for some gems is specified in a shared file, like so:
This works fine in Gitlab CI and in production. But Depfu complains with
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 like1.2.3
.