http://qs321.pair.com?node_id=11134982


in reply to Prefer Pure Perl Core Modules

Coincidentally I started a thread yesterday on a related subject. Until now, I've relied exclusively on operating system packages as integrity and authenticity checks are disabled by default, and depend on the programmer having signed the packages (which is not always the case).

System packages, on the other hand, are always checked, can be uninstalled without surprising side-effects, and are more likely to be system-compatible. Unfortunately, using exclusively system packages means not getting many nice contributions available in CPAN repos.

Usually, I tend to prefer security, efficiency and robustness over getting things done and working faster, though I recognize this often times is painfully difficult to put in practice.

So, CPAN is a great help, but I find it a shame that such problems still weren't addressed. I'm hoping they will be, before I actually depend on CPAN for anything more than getting to know it. I'd be glad to help improve it, but right now, I'm clearly unprepared for that.

return on_success() or die;

Replies are listed 'Best First'.
Re^2: Prefer Pure Perl Core Modules
by Leitz (Scribe) on Jul 14, 2021 at 13:39 UTC

    Good thread and great comments! You're right, improving the security around CPAN would help and it would be labor intense. CPAN offers a lot to Perl users, but there are significant risks.

    Take Moose/Moo for example. Once you know how to build a Perl object without them, you can see the advantages they bring. Then you have to think through the trade-offs; is the benefit given worth the personal effort required? Once you go outside of OS provided packages you have to keep OS and CPAN installed modules separate, and that can become a real challenge. If your application needs a lot of CPAN you probably want to look at compiling your own Perl and completely moving away from the OS provided packages. My desktop provides Perl 5.32 and I do CPAN installed to /usr/local. It will cause a problem if I use a lot of CPAN, so I avoid that. Other places I provide code for are limited to a much older Perl, and I have to package any module my application uses. Thus I use few. Think about how much you want to share your code, and what someone would have to do to use it. The easier you can make it for your user the higher chance you have of your code being used.

    You can also look at virtualenv and carton; they may give you what you need. I do not use them because they add more administrative overhead than I want to deal with.

    Chronicler: The Domici War (domiciwar.net)

    General Ne'er-do-well (github.com/LeamHall)

[reply]
      You can also look at virtualenv and carton; they may give you what you need.

      Maybe you mean plenv instead of virtualenv? (AFAIK virtualenv is used for python projects)

      Anyway, I think plenv helps in the sense that I can create application-specific repositories, instead of mixing dependencies for a lot of different applications, which could easily become a mess. From a security perspective, however, it remains the same situation, unfortunately.

      return on_success() or die;

[reply]

In Section Meditations