Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^3: Architecture-specific module conflicts under perlbrew

by karlgoethebier (Curate)
on May 16, 2013 at 21:15 UTC ( #1033907=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Architecture-specific module conflicts under perlbrew
in thread Architecture-specific module conflicts under perlbrew

«Yes, XS.pm got installed to the wrong directory in my @INC...»

But you don't get this well known message:

Karls-Mac-mini:~ karl $ perl -MFOO Can't locate FOO.pm in @INC (@INC contains: #...bla, bla

You get Perl API version v5.14.0...Compilation failed in require.

That damned thing seems to be available - perhaps a bad place, but it is in your @INC, isn't it?

Totally stupid "brute force" approach: Copy that thing to a place where you think it belongs (in @INC).

Do you still get this compile time error? Or do i still miss something?

Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»


Comment on Re^3: Architecture-specific module conflicts under perlbrew
Select or Download Code
Re^4: Architecture-specific module conflicts under perlbrew
by gnosti (Friar) on May 16, 2013 at 22:29 UTC
    I believe that JSON::XS was installed under perl 5.14, and found (and choked on) by a separate perl 5.16. If I install with cpanm -f I can clobber one version with another, but that sort of defeats the purpose of perlbrew, which is separate, functioning alternative perl versions with their respective modules.

    I posted that as an example of things generally going wrong, rather than as a specific glitch to overcome.

    regards,

    Joel

      "I posted that as an example of things generally going wrong, rather than as a specific glitch to overcome."

      This is, cautiously said: a "funny approach". Isn't PM (partly) about "overcoming glitches"?

      When i discovered perlbrew, i thought this is heaven-sent. But i'm skeptical about "this is the promised land" stuff.

      So i installed it on different boxes, played around with it, tried to break it, did some insane things.

      But it didn't break. It worked.

      So i recommended it for a box that is a good part of my job. The box is for monitoring more than 120 hosts with more than 1000 services.

      Setup and testing lasted about 3 month. And many people are relying on this box. And i recommended the tool on PM.

      So, if someone comes and says: "That stuff you recommend doesn't work as expected!" the bells ring.

      I try to understand why and how to find a solution.

      If i where you (assuming you are still interested in using perlbrew) i would throw away that whole stuff and start over again with a fresh setup, doing it exactly as described in the docs.

      If you can reproduce the issue, contact the author. I'm shure you get help - many rely upon perlbrew.

      Best regards, Karl

      P.S.: Ever had a broken Perl? No? So you are lucky. I had it one time on a Mac OS X server.

      I fired up cpan and went for lunch or so.

      When i was back, i had another Perl installed, tons of modules uninstalled and tons of modules new installed.

      The box was unuseable - and it was not for testing purposes.

      «The Crux of the Biscuit is the Apostrophe»

        Just because you didn't experience a problem, that doesn't mean it isn't a real problem that other people can experience (and have experienced).

        Pointing out a problem with a tool is not the same as declaring that the tool is completely useless and nobody should ever use it. Or something crazy like declaring that anybody who ever decided to use it was an idiot for doing so.

        I'm glad you had good experience with perlbrew. How many servers touch some install of perlbrew of yours seems completely pointless in relation to the problem that was found with perlbrew.

        It is like you are trying to prevent perlbrew from getting its feelings hurt. Or that you got your feelings hurt.

        I only spent a few minutes looking around when gnosti mentioned this problem and that convinced me that perlbrew really did have a serious problem with this specific case. And I realized that the fix is unlikely to be simple and that part of the problem is some fundamental problems with Perl. And I was also struck that the particulars of the problem ran rather directly into the face of the stated purpose of perlbrew and appreciated the irony of that.

        Of course, none of that contradicts with the fact of people being able to use perlbrew and never experience this problem and, of course, finding great benefit from features of perlbrew.

        Note that I also agreed with brian d foy's advice to never share install directories between versions of Perl, at least mostly. And I didn't read it as brian declaring that nobody should use perlbrew. He just said that he doesn't use perlbrew (despite gnosti's over-simplified summary and it being in quotes).

        I bet you can even install XS-using modules when using both local::lib and perlbrew and still not run into this problem. You'd have to only install configurations of Perl where it puts the "arch" directory fully nested under both the Perl (binary interface) version string and the "arch" string (and in a way that works with local::lib's choices) -- or just get lucky like by never hitting conflicting "arch" strings. And you might have to avoid weird cases like installing two instances of the same version of Perl using different configuration choices that break binary compatibility but don't change the "arch" string (if such is possible). And you'd have to install the module multiple times (and always the same version of it), overwriting the non-arch bits repeatedly.

        And, of course, you won't run into this problem if you use perlbrew w/o local::lib or with local::lib but only installing pure-Perl modules. This is something that should be clearly mentioned in the parts of the perlbrew documentation that discuss local::lib.

        But I get the impression that gnosti plans to do much more than that, to actually help get perlbrew to support making it easier to install XS modules when using local::lib without running into such conflicts. Even to make it hard to not notice when you are doing something that is going cause such conflicts.

        Hmm, in this particular case, I think it'd make more sense to install even the pure-Perl parts of XS-using modules under the "arch" directory tree. That isn't how Perl module install tools are supposed to do it. But that might have to be fixed at the core level and in the installers, not in local::lib nor perlbrew. And it'd be a good fix, even beyond this particular case, IMHO.

        - tye        

      «...I can clobber one version with another...»

      I hope i got it...

      But as i mentioned, i couldn't reproduce it under Mac OS X Mountain Lion with two different versions of Perl (or i think so).

      Perhaps it would have been better if i had posted some details of my observations.

      Unfortunately i can't access this box on weekend.

      But i can do this next week, when back in office.

      And i installed another Perl version on my box at home (Lion). If i find the time i'll give it a try (but i'm not shure if this makes sense).

      I don't have a Linux box for testing this issue but i think this doesn't matter.

      Please note, that i didn't want to be harsh.

      I just want to understand this story and bring it to a good end - if possible.

      Update:

      Sorry, i still didn't find the time to check this, but i'll be back ;-)

      Best regards, Karl

      «The Crux of the Biscuit is the Apostrophe»

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1033907]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2014-07-30 01:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (229 votes), past polls