Hey everyone - Chris drew my attention to this discussion:
On Wed, Aug 7, 2013 at 7:22 PM, Chris Marshall wrote: > On Tue, Aug 6, 2013 at 7:23 PM, Michael G Schwern <schw...@pobox.com> wrote: > > > > I see two distinct problems you're driving at. One is meta data about > > what platforms/environments/external_prereqs a module supports. The > > second is making a module work on more platforms. Separating them is > > important, else people will balk at the extra work and responsibility > > implied by #2. > > The idea was to refine the Alien manifesto it easier to implement > and use external packages via Alien::XXX. > > > And there's the third implied problem of "you should care about > > something other than your own machine" which will always be there. > > Actually, this is a fact. The proposed clarification hopes to > address some of the resultant failure to reach its full potential > of Alien modules. > > > To address the second, first. For a regular module, this is a valid > > target, because the module author has control over all the code. > > Alien modules are different. They're bundling an existing, often > > large and old, project. If that project is highly > > Unix/libtool/etc-centric, it's going to be a lot of work on the part > > of the Alien module author to make it work on anything else. Both > > technically and socially (ie. getting the upstream project to budge on > > their platform limitations). Even projects which ostensibly work on > > Windows, for example SVN, the Windows build process is often tortured. > > > > It's a valid problem. Asking the Alien authors to put in all that > > extra work is above and beyond. Often Alien authors are in the same > > boat you are, they just need it as a prereq. That's my case with > > Alien::SVN. IMO that should be handled upstream, within the original > > project. Once upstream platform support is made better, then the > > Alien module is better. > > > > To the idea of stating what platforms/environments a module works on, > > this is a valid problem. Solving it means, again, a lot of work on > > the part of the Alien author to figure out what platforms/environments > > it works on. > > > > One way out is to declare what platforms your module *doesn't* work > > on, something you often know better. For example, one > > can be pretty sure whether your thing is going to work on Windows. > > The idea here is that an Alien::XXX module should include a basic > statement of which platforms could be expeced to work or not. > Once you have documentation (best effort) than updates can be > made on the basis of further test results or input from other > users/developers/implementers. > > > However, I find that too coarse and prescriptive and likely to fall > > out of date. > > I think if Alien::XXX were to report a FAIL for any instance > when it was either unable to locate an existing, appropriate, > installed library/package, then it would be a simple matter to > determine where Alien::XXX has worked and hence where it likely > *could* work. (N.B., This is not what the test reports say for > perl modules but in the Alien case it seems to pass my "does it > do the right thing?" test. > > Personally, I track my module CPAN Testers output and if my > Alien::XXX module all of a sudden changed its PASS profile, I > would be *delighted* to update the documentation to reflect that > fact. I would be happy to submit a doc patch to an incorrectly > categorized Alien module too. > > > A better way out is the descriptivist approach: declare all the > > external tools it needs. If your environment has all those tools (or > > good enough emulations) it'll work. This adds two problems: figuring > > out what all those tools are (and what versions... GNU or BSD or what) > > and then declaring them. The former is grunt work, and tracking > > minute changes to the upstream build system if it's shell based. The > > latter, we don't have a good way to track external dependencies. > > Wait, yes, we do! Alien modules! > > > > So, oddly enough, a solution to the problem of declaring external > > dependencies for Alien modules is... more Alien modules! > > Alien::libtool, Alien::make, etc... It works within the module > > system. > > > > Perhaps a new category of module is needed. Instead of installing an > > external tool, it just checks for the existence of and capabilities of > > existing tools. Like Devel::CheckOS or (more ambitiously) > > ExtUtils::CBuilder. Sort of like autoconf does, but in small pieces. > > For example, you might write one which checks for information about > > the libtool installation. And if it doesn't exist, perhaps provides > > information about how to get it. > > This (say Alien::Base::CheckLib) plus documentation of > applicability was the jist of my proposal. See the original RFC > with the link to the first module-authors post by me. I think > a _supplement_ to the POD info on usability would be something > like a reference the the CPAN Testers matrix for the module > and a recommendation to run a test install to determine any > platform specific diagnostics. Ideally, the build/install/fail of > Alien::XXX could include information on where to manually get and > install XXX appropriately. > > That would be simple for the Alien::XXX user and offer real > information to the perl/guru/developer who needs to understand > more about the build/install/detect failure so it can be > resolved. > > The hope is that Alien::XXX modules stop being 100% solutions > that cannot be uniformly relied upon to modules with a reasonable > expectation of some level or true cross-platform support (where > possible) even if it bails out but tells you how to fix things on > your own. > > I appreciate all the discussion and the abore response collects > the key results as I see them into a more specific plan for > updating the Alien manifesto. > > --Chris > > > That's my thoughts. > > > > > > On Sat, Aug 3, 2013 at 10:05 AM, Chris Marshall <devel.chm...@gmail.com> > > wrote: > >> > >> All- > >> > >> I'm looking for feedback on a post from last month > >> to the module-authors mailing list: > >> > >> http://www.nntp.perl.org/group/perl.module-authors/2013/07/msg10026.html > >> > >> The gist of which the current approach for Alien > >> module implementation is not very effective since > >> the platforms that have not supported or have > >> broken implementations are precisely the ones > >> that most need the Alien modules. > >> > >> I would appreciate any other idea for how to get > >> better Alien module support. My specific interest > >> is for PDL which has a number of components > >> based on external libraries for which the availability > >> of corresponding Alien::XXX modules would > >> greatly improve portability and buildability of PDL. > >> > >> Thanks for your prompt feedback---assuming > >> this attempt makes it through the filters at cpan.org. > >> > >> --Chris > > Chris's ideas make me think of two points: 1) Documentation should include information about platforms that the author *thinks* are supported. The first is an enhancement to the Alien manifesto and a call for authors to be a bit more detailed in their documentation for what they know works, or doesn't. It doesn't insist that they test everything, but simply that they indicate what they know. 2) We should be able to leverage the amazing Perl testing infrastructure to get more useful information about why an Alien module succeeds or fails. Is there a reasonable way within the current test framework to get more useful failure diagnostics? Can we recommend a recipe for Alien modules so that they get these diagnostics? Addressing Leonard's concerns, might it involve a separate namespace, such as Alien::Test::XXX, under which we publicly declare we will "break" the usual conventions for test output? The first idea is easy: just add the recommendation to the manifesto. The second might be easy too, but I don't know the testing infrastructure well enough to provide a useful recipe. David -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
