Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Should cpanminus be part of the standard Perl release?

by marto (Cardinal)
on Jun 01, 2018 at 10:47 UTC ( [id://1215618]=poll: print w/replies, xml ) Need Help??

Vote on this poll

Yes!
[bar] 103/72%
No way!
[bar] 40/28%
143 total votes
Replies are listed 'Best First'.
Re: Should cpanminus be part of the standard Perl release? -- MSWin32
by Discipulus (Canon) on Jun 06, 2018 at 11:17 UTC
    dear marto and all,

    I used cpanm client and it's cool and a has a cleaner interface and some interesting experimental features, notably the ability to uninstall modules, not available in the classic cpan classic client.

    But, as stated above by Tux with reason a Linux fan, cpanm it's not fully functional on MSWin32 and this is very common for many genial pieces of code by miyagawa. If this is acceptable for example for some webserver PSGI aware (even me I'd put on linux only) it's not for the client used to install modules.

    We can like or dislike MSWin32 OSs but they are here and they have big slice of the market. I'm not a fan but I work with it daily so I must be very careful in my choices. I jumped on the strawberry perl charriot many years ago and I'm very happy with it: now I can use perl on MSWin32 the very same way I can use it on linux.

    Let's see something:

    me@work>cpanm --version cpanm (App::cpanminus) version 1.7044 (D:\path\perl5.26.64bit\perl\sit +e\bin/cpanm) perl version 5.026000 (D:\path\perl5.26.64bit\perl\bin\perl.exe)

    Noticed the path? Is not File::Spec a core module since years?

    Infact..

    me@work>cpanm --self-upgrade Can't find Unicode property definition "e" in regex; marked by <-- HER +E in m/^D:\path\pe <-- HERE rl5.26.64bit\perl\site\bin/ at D:\path\pe +rl5.26.64bit\perl\site\bin/cpanm line 32.

    Is not the case to translate directory seprators? or to use quotemeta and qr and eval the regex? Ok it' just an alias fo cpanm App::cpanminus but the latter works fine: App::cpanminus is up to date. (1.7044)

    Let's test some module:

    me@work>cpanm --test-only Text::Xslate --> Working on Text::Xslate Fetching http://www.cpan.org/authors/id/S/SK/SKAJI/Text-Xslate-v3.5.6. +tar.gz ... OK ! Bad archive: Text-Xslate-v3.5.6.tar.gz ! Failed to unpack Text-Xslate-v3.5.6.tar.gz: no directory ! Failed to fetch distribution Text-Xslate-v3.5.6

    Ouch it's my cpanm configuration wrong or broken?

    me@work>cpanm --test-only -v Text::Xslate cpanm (App::cpanminus) 1.7044 on perl 5.026000 built for MSWin32-x64-m +ulti-thread Work directory is D:\path\perl5.26.64bit\data/.cpanm/work/1528273179.7 +400 You have make D:\path\perl5.26.64bit\c\bin\gmake.exe You have LWP 6.26 You have D:\path\bin\UnxUtils\usr\local\wbin\tar.exe, D:\path\bin\UnxU +tils\usr\local\wbin\gzip.exe and D:\path\bin\UnxUtils\usr\local\wbin\ +bzip2.exe You have D:\path\bin\UnxUtils\usr\local\wbin\unzip.exe Searching Text::Xslate () on cpanmetadb ... --> Working on Text::Xslate Fetching http://www.cpan.org/authors/id/S/SK/SKAJI/Text-Xslate-v3.5.6. +tar.gz ... OK Unpacking Text-Xslate-v3.5.6.tar.gz ... META.yml MANIFEST ! Bad archive: Text-Xslate-v3.5.6.tar.gz ! Failed to unpack Text-Xslate-v3.5.6.tar.gz: no directory ! Failed to fetch distribution Text-Xslate-v3.5.6

    Mah? I have all! let's try dear old cpan

    cpan> test Text::Xslate Database was generated on Wed, 06 Jun 2018 07:47:04 GMT Running test for module 'Text::Xslate' ... All tests successful. Files=191, Tests=2740, 130 wallclock secs ( 0.88 usr + 0.41 sys = 1. +28 CPU) Result: PASS SKAJI/Text-Xslate-v3.5.6.tar.gz D:\path\perl5.26.64bit\perl\bin\perl.exe ./Build test -- OK

    So, in conclusion, every better, modern, client upgrade will be welcome if it runs as well and everywhere as the older one.

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
      notably the ability to uninstall modules,

      I agree that's cool

      UnxUtils are from 2003, tar.exe has had many bugfixes since
        Hello Anonymous Monk and thanks for looking to this old post,

        are you arguing that my cpanm test failed for an ancient tar.exe I have in path, specifically from UnXUtils? The very same tar.exe is supposed to be used by the succesful cpan attempt to extract Text::Xslate ..so it should be not tar.exe the guilty. Even if not provided in cpan conf tar.exe is the same:

        cpan> o conf ... tar [ ] ... cpan> quit Lockfile removed. which tar.exe C:\EX_D\ulisseDUE\bin\UnxUtils\usr\local\wbin\tar.exe

        L*

        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Should cpanminus be part of the standard Perl release?
by Tux (Canon) on Jun 06, 2018 at 08:04 UTC

    Some reasons for not including it I can come up with:

    • It doesn't run on all platforms and/or architectures supported by the perl core, so tests will fail
    • It doesn't offer anything that cpan does not already do (enlighten me if I'm wrong. I don't mean cpanm does it faster or easier or nicer. I mean something that isn't possible with cpan and is a killer feature everyone should be using)
    • Nothing in the core depends on it, so it doesn't add to features of perl itself, only to (some) user experience
    • It is extremely easy to install after perl itself is installed (on supported systems)
    • It does not (yet) fully support distroprefs, something vital for distributors
    • It add maintenance costs and testing time
    • It might be replaced with something even better

    Enjoy, Have FUN! H.Merijn
Re: Should cpanminus be part of the standard Perl release?
by atcroft (Abbot) on Jun 01, 2018 at 13:16 UTC

    (I originally made comments similar to the below in the ChatterBox on 2018-06-01T08:43:37-0500, but adding here for comment by others.)

    As some may not be familiar with cpanminus (or other CPAN clients), perhaps it might be of benefit to provide (possibly as one or more tutorials or meditations) a comparison of cpanminus to other common CPAN clients, showing the strengths (and, my hope, the weaknesses also) of both, and illustrating the reason(s) you believe there is (or is not) a benefit to doing so.

      "perhaps it might be of benefit to provide (possibly as one or more tutorials or meditations) a comparison of cpanminus to other common CPAN clients, "

      I'm working on something as a background task, which has a hefty section on this very subject. I'll keep you posted.

      "and thinking that if one were experimenting with different CPAN clients how much space could be "wasted" in the process."

      cpanm has it's advantages, one being speed, it's simply a lot faster. It's also much lighter on resources, where cpan dies, e.g. installing things on an embedded, or otherwise resource limited system.

        cpanm has it's advantages, one being speed, it's simply a lot faster.

        How can that be? cpan and cpanm are simply front ends for the installers provided by the distributions.

      That would be awesome! I can't count the number of times I've asked why one would want to use cpanm, and the only answer I've gotten (that didn't lie about cpan) was that it works better on systems with less space (such as embedded systems), and that it hides the output of the installation tools when there's no error (which still hides useful information). (Obviously, cpanm is less configurable, but noone actually needs the extra configurability of cpan, so I won't count it against cpanm).

        Noone? Please count again. Maybe/probably a minority, but I personally know quite a few people that use the configuration of cpan to some extent. I have no idea if any of the other CPAN clients supports distroprefs the way cpan does. If cpanm does not (I would not know, I don't use it), it would be the reason not to use it.


        Enjoy, Have FUN! H.Merijn
Re: Should cpanminus be part of the standard Perl release?
by shmem (Chancellor) on Jun 01, 2018 at 12:51 UTC

    Too few options. Some more:

    • it should no matter how
    • it should, but it ain't
    • it should, but only as a drop-in replacement for cpan
    • it should because I'm the developer and p5p should cope with it, I'm done
    • it shouldn't because it kills the holy cow "backward compatibility"
    • it shouldn't because of dependencies not in core
    • it shouldn't because I'm a p5p and there's enough to do yet
    • it shouldn't because it sucks (explain how)
    • it shouldn't because "minus" is bad marketing lingo
    • other (say what?)
    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

      So essentially, yes or no and explain in a reply why?

        Essentially, yes. Since there's only 'yes' and 'no' and people are generally too lazy to explain why they choose either, some common arguments would help them to explain without needing to do so, and make those more specific answers countable.

        At PerlMonks, we can comment; but in e.g. political polls questions are often carefully crafted to steer away from the reasons for consent or rejection (which of course isn't your intention here). In this poll, the interesting thing is not 'if', but 'why ·/· whynot' and what could be done about that - i.e. what is the reason with most weight for either choice.

        perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
Re: Should cpanminus be part of the standard Perl release?
by wjw (Priest) on Jun 04, 2018 at 09:36 UTC

    I simply find cpanm does all I want to do including working with PerlBrew very nicely. I used cpan for years and have no real complaints. Configuration of cpan is no real problem since most of it just self-configures.

    That said, I started using cpanm when I started using PerlBrew and have yet to find a reason not to, so I do. I do find that it is faster than cpan for some reason. Maybe that is wishful thinking on my part. I have not measured either one.

    I can certainly understand p5p folks not wanting yet another thing to do however. Bottom line is that I like cpanm and use it, and yes it would be nice to have it simply be there. But installing it is so simple that it probably is not worth the time invested to make it part of Perl releases. (I work almost exclusively on Linux, so I should not and do not represent those folks who work on MS stuff). Just my $0.02 worth....

    ...the majority is always wrong, and always the last to know about it...

    A solution is nothing more than a clearly stated problem...

Re: Should cpanminus be part of the standard Perl release?
by davies (Prior) on Jun 04, 2018 at 09:54 UTC

    I don't know much about the issues related to a module being "core" or not, but I have found it a nuisance on Raspberry Pis to have to install cpanm as the large dependency chains of some modules makes installation die silently with cpan. Therefore I would like to see it as standard at least on the RPi. I would imagine that it would be unwise, if not impossible, to have it as "core" on Raspbian and not in other implementations, so my vote was "yes". But I may have been guided my my ignorance and will happily slouch corrected.

    Regards,

    John Davies

      There is a standalone version of cpanminus. You'd just need curl or wget to install it.
Re: Should cpanminus be part of the standard Perl release?
by marto (Cardinal) on Jun 01, 2018 at 11:20 UTC

    If not, why not? :P

      Cause perl5-porters, thats why :)
Re: Should cpanminus be part of the standard Perl release?
by RedElk (Hermit) on Jun 28, 2018 at 17:48 UTC

    I voted no. cpamn just feels like a separate utility to me.

View List Of Past Polls


Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (6)
As of 2024-03-19 09:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found