Alien::Base and Module::Build
TL;DR - if you have an Alien::Base based Alien module, please update configure_requires so that it depends on Alien::Base::ModuleBuild instead of Alien::Base, and (this part is key) make a release.
This is technically more correct, and it will also future proof your module in the event that Alien::Base::ModuleBuild gets spun off from the rest of Alien::Base. There are a number of motivations making such a move. Please join us on GitHub or the #native IRC channel if are interested in working on the next generation of of Alien::Base.
Perl programmer with an interest in Alien and FFI technologies. Primary developer of FFI::Platypus and Alien::Build.
Can I try to change your mind? The Alien::Base stuff already on BackPAN is never going to be fixed; how about making an Alien::Base::Core (or some such) instead, for the installer-independent logic, and then Alien::Base::MakeMaker for the new EUMM stuff. If desired you can eventually leave Alien::Base as a mostly-docs package that punts to A::B::MB when used as configure_requires (with a deprecation warning if you must, as long as you keep the punt).
That way, nothing ever breaks, not even history. The only price is one extra namespace and a slightly uglier name for the package the logic is in.
Alien::Base is already completely independent of installer logic. The modules that have configure_requires of Alien::Base are simply wrong. Alien::Base could be an empty isa of Alien::Base::Core I suppose, though I think there are educational and branding challenges there. I'm open to alternatives, hence the GitHub issue to discuss.
How many are there? If there are only a handful, then OK – I guess we can eat the breakage and move on. But, maybe we still shouldn’t. And if there’s a substantial amount of them, then it would definitely be really good to avoid having to roll over everything on CPAN and breaking the historical record.
Has this always been a wrong thing to do, or did declaring a configure_requires on Alien::Base used to be the advertised way of doing it? If it used to be sanctioned, then I’d additionally consider it a matter of fairness to users to choose the solution that won’t break their stuff, if at all feasible. And it seems easily feasible here.
(Of these two, the former is the more important concern to me. The extent of potential breakage is a reality that demands consideration, however it may have come about. Promises and blame are only peripherally relevant to my way of thinking as far as that is concerned.)
FFI::Platypus seems to be good product. I am reading documentation now.