Re: What am I doing wrong? A bad end-user experience

[Re-sending to list:]

On 12.09.26 07:05, demerphq wrote:
> 
> Afaik useversionedarchname only versions XS files, it does not version 
> perl files, so while it reduces some of the issues of upgrading it 
> definitely won't fix them all, and you are likely to end up in a world 
> of pain regardless.  Might as well look at using PREFIX instead of 
> INSTALL_BASE if that is the way you want to go.


This is a bit subtle. useversionedarchname versions everything that 
installs into archlib. With ExtUtils::MakeMaker at least, this is all 
files from any distribution that builds anything in blib/arch. Which by 
default is XS/C code.

So: A pure-perl distribution will have an unversioned .pm file in @INC, 
but an XS distribution will have all of its .pm and .so/.dll/etc in the 
versioned arch directory.

(This is just the default. For example, when Sys::GetRandom::PP was 
still based on h2ph, I made it install some of its pure-perl bits into 
blib/arch because they were machine dependent: 
<https://metacpan.org/release/MAUKE/Sys-GetRandom-PP-0.05/source/Makefile_PL_settings.plx#L34>)


> Better to use CPAN to dump a bundle list of your modules and then 
> reinstall the new tree entirely.
> 
> There is no reliable way to know that a module is safe to upgrade 
> without actually trying it, and you might find the breakage exists at 
> the worst time.
> 
> Upgrading bypasses retesting on the new perl, etc, so it is a very low- 
> confidence approach to solving the upgrade problem.

I don't disagree in general, but 'cpan -a' + reinstall requires planning 
ahead. The point here is to mitigate the issue when one of the system 
package updates happens to upgrade perl. Leaving the pure-perl modules 
in place and masking off anything XS related may not be 100% safe, but 
in practice it works pretty well. (And it won't leave you with 
half-broken modules that cpan thinks are present but you can't actually 
load without errors.) So I think it's a net improvement over the status quo.

(And if this approach didn't work well in practice, we probably wouldn't 
have tools like Object::Remote or App::FatPacker.)

"Upgrading bypasses retesting" is funny to me because I've worked on 
several Perl projects that use carton + cpanfile for their dependencies. 
And carton never runs tests. It just does 'cpanm --quiet --notest'. 
Again, it seems to work in practice or we (or rather the carton author) 
would have heard more about it.

(BTW, did you mean to send this to me directly and not to the list?)

[Turns out no, it was a mistake.]