Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: How to tell EU::MM to install a pure-perl module into an architecture-specific location

by NERDVANA (Deacon)
on Sep 24, 2022 at 07:29 UTC ( [id://11147101]=note: print w/replies, xml ) Need Help??


in reply to How to tell EU::MM to install a pure-perl module into an architecture-specific location

At that point, Module::A becomes immediately available to all 9 architectures, even though it has not been tested against 8 of them. This is an unsatisfactory state of affairs, IMO.

Even more unsatisfactory, Module::A would be available on all 9 architectures possibly lacking many of its XS dependencies, and completely fail to work until someone ran cpanm under each other architecture to get the dependencies installed.

How do module authors generally deal with this issue ?

I don't think any module authors ever deal with it. This general usage pattern can't be fixed by a single module author; it would require all pure-perl modules with XS dependencies to always be installed in the architecture-specific location. I've never used this usage pattern either; every perl of a different arch that I've used has always had a complete standalone lib directory. (using perlbrew or plenv) I would guess the only time the multi-arch directories are actually intended to be used are when you have perl libs shared on NFS or a binary package repo or something like that. In that case, an administrator or distro maintainer would ensure the state of each arch before releasing the changes to the user base.

Since you have to install your module 9 times anyway, you might consider automating it with something like Carton. Carton records the version of every module dependency installed, and would re-install all the dependent modules as you re-run it under each arch.

  • Comment on Re: How to tell EU::MM to install a pure-perl module into an architecture-specific location

Replies are listed 'Best First'.
Re^2: How to tell EU::MM to install a pure-perl module into an architecture-specific location
by syphilis (Archbishop) on Sep 24, 2022 at 11:26 UTC
    I don't think any module authors ever deal with it.

    I think you're right about that.
    And, wrt my own modules, I'm now happy to utilize the solution that hippo provided.

    But there's the question of what to do about other people's modules on CPAN.
    For example, there's the pure-perl module Math::AnyNum that depends upon a number of perl extensions.
    Should I suggest to the Math::AnyNum author that he also apply hippo's fix to his module ?
    Or should I just deal with it myself ? - either by patching the Math::AnyNum Makefile.PL, or by doctoring the make install command as suggested by hv ?
    I tend to think that it's probably up to me to deal with it privately, but I might mention the issue to the Math::AnyNum author to ensure that he's at least aware of the issue.

    Cheers,
    Rob
      I tend to think that it's probably up to me to deal with it privately

      I agree. Any pure-perl module, regardless of whether it depends on impure modules at any depth, should go in the architecture-independent lib path by default. How else would you deal with the case where the deep dependencies change either to or from XS? Or vary depending on other factors?

      Your particular use case is far enough from the mainstream that it is IMHO up to you to set the necessary flags when installing such modules to meet your specific requirements.


      🦛

        Your particular use case is far enough from the mainstream that it is IMHO up to you to set the necessary flags when installing such modules to meet your specific requirements.

        Cool ... I can live with that ... and thanks for taking the time to express that view.
        However, although my use case is not mainstream, I'll point out that it's still (AFAICS) an officially endorsed use case.
        And that muddies the waters a little, IMO ... but probably not enough to make much difference.

        I assume that there's no objection to my enforcing the installation of my Module::A (Math::FakeDD) into $Config{installsitearch} for all who attempt to install the module.
        Someone should let me know if that's a bad assumption.
        (There's no guarantee that anyone other than me would want to install that module, anyway.)

        Cheers,
        Rob

        Update: Math-FakeDD-0.05 also now available at cpan.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (2)
As of 2024-04-19 20:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found