Is that good practice? Unless there's some platform specific reason to install a perl module in my system perl, a containerized perlbrew install will always be safer than using system perl.
Like perlbrew, Alien's goal is to avoid updating or relying on system binaries or libs. When the system version of a lib/binary doesn't meet the module author's specific requirements, a local version is downloaded or built. If a module is written for one version of a lib, forcing an up- or downgrade of the system install of that lib/binary might bring the sky down on your head. Similarly, a system upgrade might break a perl module that isn't yet compatible with a more recent lib/binary. Having local dependencies separate from the system package manager will always be less complicated and disk space is cheap enough that having a separate perlbrew (that can be replicated, upgraded, deleted, etc.) and a 'stable' system perl that is unchanged from the upstream distribution won't break the bank.
Not all module authors use ExtUtils::MakeMaker so any functionality built only into it wouldn't work everywhere. Perl's package installation ecosystem is so fragmented that Alien (as much as I dislike the alienfile system that backs most of them) is the current best option to try and wrangle everyone into a single "Way" to manage binary dependencies. Maybe, one day, we'll have a single, proper module install system built and designed as a part of the core language spec like Rust's cargo/crate which has a way to define binary dependencies built in. Maybe cpanfile will continue to grow in adoption and become that.
Anyway, we're both in the right place for random thoughts. :)
In reply to Re^3: ExtUtils::MakeMaker : delcare a binary dependency
by SankoR
in thread ExtUtils::MakeMaker : delcare a binary dependency
by bliako
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |