Ruby/Comparison
< Ruby
Comparison to the previous policy
Strictly speaking the approach with dependencies search over the only require calls to the modern time is significantly restricted by the following points:
- this method calls are not always exactly detecting the real dependencies list for gems, and increasingly for Gemfile-based projects, insofar as there may be non-mandatory calls to require in the code, which are framed in the begin-end code that makes the call optional;
- for Gemfile-based projects the require calls are implicit and executed by bundler indirectly based on the Gemfile and .gemspec files analysis, if any, then bundler monitors for integrity of the current module development environment, this leads to that the require call to external module, in case the dependency to the module isn't declared in the Gemfile, will raises the module not found error that will block the project development (in case of rpm building to build error);
- a name of external module is not always can be inferred from analysis of require call lines, since some modules have non-standard naming in a relation to their gem, for example a gem can have name 'foo-bar', its modules can have FooBar, FooBar, или Foo/Bar, but correspondence to those files will have foo_bar, foo/bar, and the last is falsely triggered on foo module name;
- implicit loading of the external project modules, because bundler make the calls to that modules itself;
- technique for dependency detection from require isn't capable to control API-version of the dependent package, when it is changed, especially in case when the package requires old and non-updated API.
Thus, in modern times is it more safely to use Gemfile/.gemspec file pair analysis to determine the dependencies.