in reply to Perl::Minimal -- the good, bad, and the ugly...

To some extent, the *::Tiny "namespace" addresses this. But I get the feeling that the real issue is that Perl has simply become bloated over time. If nothing else, there are probably quite a few modules in CORE that really don't need to be there to have a working install. Yes, they are handy, and if not part of CORE would have to be brought in from CPAN for many other modules. But some of the most essential modules for many applications are not part of CORE, i.e. DBI. I say leave some of those others out and let them come in when installing something from CPAN that needs them.

(This was almost exactly the stance taken with v5.20 with the removal of CGI from CORE.)

I stopped being able to do a perlbrew install of any relatively recent version of Perl on my hosting service because of execution runtime limits some time ago. My provider (a very popular one) limits command line scripts to only 15min before being shutdown. That means that to install a Perl with perlbrew I have to tell it to NOT run the tests, then come back and run the test suite manually. This is entirely due to the large number of modules in CORE now.

It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Replies are listed 'Best First'.
Re^2: Perl::Minimal -- the good, bad, and the ugly...
by davido (Cardinal) on May 30, 2014 at 16:21 UTC

    I stopped being able to do a perlbrew install ...on my hosting service because of execution runtime limits...

    perlbrew install -n Perl-5.20.0 will skip testing. Your application probably has its own test suite that is much shorter running than Perl's. If that suite passes, it may not be necessary to run the Perl install through its tests. ...maybe not an optimal solution, but it might be good enough until the host sees the light.

    On one of my systems the install of Perl 5.16.3 takes about five minutes by skipping tests. Lowly Perl 5.8.9 takes about 2 minutes. Both fall within the 15 minute limit set by your host.


    Dave

[reply]
[d/l]
Re^2: Perl::Minimal -- the good, bad, and the ugly...
by taint (Chaplain) on May 30, 2014 at 02:15 UTC
    Aside from the "provider stuff". I agree. But I guess that's the point; exactly what are the MUST-HAVE's?

    Is it possible to come up with enough of them to know that anyone tempted to use "Minimal Perl" would know that they will only need to add a few Modules to make it work for their Project/App?

    Thanks for the feedback boftx.

    --Chris

    ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]

      I'd say the must-haves are:

      1. strict
      2. warnings
      3. utf8
      4. Carp
      5. Exporter
      6. List::Util
      7. Scalar::Util
      8. parent
      9. Tie::Hash::NamedScalar and File::Glob because they get auto-required by core under various circumstances.
      10. Everything necessary to bootstrap a CPAN client such as cpanminus.
      11. Test::Harness
      12. Test::More

      If you wanted to throw some other stuff in as a bonus:

      1. HTTP::Tiny (though this is probably necessary to bootstrap a CPAN client)
      2. JSON::PP
      3. Class::Tiny
      4. Role::Tiny
      5. Class::Method::Modifiers

      In practice there are quite a few modules which are only available as part of the core Perl distribution, and are not on CPAN in their own right. This means that if you cut them out of your Perl install, users cannot obtain them from CPAN. So you probably need to keep them.

      use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
[reply]
        Hello, tobyink.

        Thanks for taking the time to suggest a list of "Must Have's"!

        I really appreciate your input. As I'd be inclined to think your activity on the CPAN (~tobyink) to provide, perhaps, more insight to the Must-Have's. :)

        As to:

        In practice there are quite a few modules which are only available as part of the core Perl distribution, and are not on CPAN in their own right. This means that if you cut them out of your Perl install, users cannot obtain them from CPAN. So you probably need to keep them.
        This one is a Moving Target (see my comment in your Re: Perl 5.20.0, and perl What is new for perl v5.20.0) for greater context. As a possible remedy; it seems worthwhile to/for someone to maintain such "depreciated", not-included, or CORE-only modules. Which also speaks to your suggestion for including CPAN-enabling Modules.

        Thanks again, tobyink, for taking the time to compile a list of Must-Have's. Greatly appreciated.

        --Chris

        ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]
      I wonder what the odds are for discovering the top N, require statements?

      First thought was using the statistics at the CPAN to garner the requires of the top Mod's. But given those stats are so long lived. I'm afraid that might skew the results too much, given there are mirrors, and they don't correlate, concatenate the data with one-another. Nothing that I'm aware of is available for such data.

      More thought, and investigation required.

      --Chris

      UPDATE correct myself (note strike out).

      ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]

In Section Meditations