That Alien idea is alien to me. In Linux, with everything being installed (good practice dictates anyway) with the system package manager, I fail to see how writing this Alien module will be an easy task. OK, easier than installing from a tarball but you are essentially creating a perl interface to every package manager out there.

Bottomline, Perl modules must be integrated (even more, I know fedora offers perl modules - often outdated - via its package manager) to the system's package manager so that it understands modules' binary dependencies and installs them as it knows how to do best. But where does that leave perlbrew and the "don't mess with system perl"? dnf makes it very difficult to have parallel installations (e.g. older versions). But there exists the alternatives framework which could be used - I mean by the package manager. And perlbrew be integrated into this framework.

And so for a start, wouldn't it be easier for authors if ExtUtils::MakeMaker had also binary dependency checking with transparent, to the author, finding libs and executables? The perl facility (for discovering binaries, i think that's OK no?) is there. That can make the life of package-manager devs to dare some innovation in this field.

To be faire, perhaps, this is a rare case where lame windows can boast, because of Perl distributions are more centralised (from what I read here) and take over from windows, which invariably makes things better I guess.

Anyway, SankoR thanks for the stimulus to mumbling my random thoughts

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. :)