Alien::Base - progress and problems
After a busy Christmas season and being engrossed in my upcoming thesis defense I have found it hard to find too much time to focus on Perl projects. Still Alien::Base has been on my mind, and happily it has been on the minds of others too!
In this report I want to focus first on the high points. Far and away my high point has been that in my apparent absence others have taken up the mantle. I have gotten bug reports and pull requests from preaction, giatorta, amannb, mokko, tobyink and as always productive conversations with David Mertens. It helps in a tough project like this has been to see the excitement of other developers, waiting for me to finish this project.
Several bugs have been fixed, others have been identified. I hope to have another dev release out soon. Further I plan to release a version of Alien::GSL which depends on Alien::Base to CPAN not long after that.
Now for the bad news. While it seems that Alien::Base is coming to a preliminary form of “completion” I have started to notice a disturbing trend coming from CPANtesters. Let me preface this by saying I think CPANtesters might be the killer app of CPAN; it is spectacular and I have said so before. There is a problem though.
Because I wanted to be sure that testing was done with properly installed modules, I created two phony distributions: Acme::Alien::DontPanic which provides a tiny C library of my own creation, and Acme::Ford::Prefect which relies on it. For this reason, when considering the test results for Alien::Base, the results of these modules must be considered as well.
As I have noted before, certain platforms (Mac OSX) need to know the full path of the library’s final install location at build time. The only way I was able to overcome this problem was to have Alien::Base build the library in a temporary location and reference the final location in the build system. Then when the module is installed, the build tool’s install command is issued. The library’s build system therefore avoids the Perl build system. Let me say this a different way, the built library never lands in a blib directory before moving to its final location.
Now I want you to note, that I have taken special care to make sure that Alien::Base refreshes the installation packlist and all-in-all there should have been no adverse effects from this plan. It wasn’t until I started to get failing tests for the packlist handling on Acme::Ford::Prefect that I noticed the problem. While I was able to prevent those problems from being reported, they belied a deeper problem.
This brings us back to CPANtesters. When testing some module, many of the CPANtesters smoke testers don’t actually install the dependent modules. What they do is build each dependent module, then add all the relevant blib directories to the @INC array. This is a clever system, it means that a fresh dependency chain is available for each test, it means that the testing platform is not affected by installing all these modules. Unfortunately its not testing a real install environment. For most people and for most modules this is fine. For Alien::Base as currently constituted however, its a very real distinction.
On platforms where this library path information is not problematic, Alien::Base will work correctly, even under CPANtesters blib scheme. For platforms that suffer from this problem, I believe that Alien::Base will work correctly, but not under the blib scheme. Therefore no dependent modules will be able to successfully dynamically link to the provided C library.
Until Alien::Base-based modules can install and test on the three major platforms, I hesitate to call Alien::Base completed. I think I’m rather close to declaring victory on 5 of those 6 goals, however if CPANtesters testing on Mac is broken, I’m still stuck saying that there is work to be done before any victory may be declared.
Perhaps there is some way that CPAN testers can work with me to avoid this problem, admittedly I haven’t talked to them about this. If anyone with more knowledge on the subject wants to comment below, email me or file a github issue, please do.
As I delve into the deeper Perl magic I like to share what I can.
That would indeed be a good step to take. I’ve encountered similar bogus test failures with some modules - Moose seems to be another one that doesn’t seem to show up in @INC properly with the ‘blib’ trick.
The solution I chose in this case was to request that certain testers don’t test my modules - http://www.nntp.perl.org/group/perl.cpan.testers.discuss/2013/01/msg3045.html
Joel,
I just want to say that I really appreciate your work on Alien::Base. I think it’s going to be one of the most important tools on CPAN in the near future and I’m glad someone has the brains to figure out how to do it.
Joel -
I recall at some point that we discussed adding code into Alien::Base that would detect whether or not it was being run via a CPAN smoker via the AUTOMATED_TESTING environment variable, the PERL_MM_USE_DEFAULT environment variable, or some such. That would allow you to pick to install the library in the blib location. Did you pursue this any further? Or perhaps the CPAN Testers have another preferred environment variable?
P.S. For any responses, use _ to get underscores that don’t italicize. :-)
David, this doesn’t fix the problem. Say you want to test some module that depends on an Alien:: module. Since the dependency wont work from blib, neither will the dependent module. This breaks the entire philosophy of CPANtesters and of Alien for that matter.