Re^4: Unwritten Perl Books

[adrianh]

very few professional software development environments would be based on the CPAN packaging system (it could probably be done, but would seem like a kludge

I'm curious why you think the CPAN packaging system would seem like a kludge. I've always used EU:MM (or more recently Module::Build) for my commercial work with great success. Why would I bother reinventing the wheel?

The ways people really do it would be interesting to hear about (just as an example: is there any standard at all outside of the h2xs world about where to put test files and what to name them?

I often find myself with a hierarchy of test classes that I put in t/lib that mirrors the files in lib/.

[doom]

adrianh wrote:

doom wrote:

very few professional software development environments would be based on the CPAN packaging system (it could probably be done, but would seem like a kludge

I'm curious why you think the CPAN packaging system would seem like a kludge. I've always used EU:MM (or more recently Module::Build) for my commercial work with great success. Why would I bother reinventing the wheel?

At a guess we're thinking about slightly different situations. I'm envisioning something like a commercial website, with a number of developers working simultaneously on several hundred modules, but with out any need to package them up and ship them to someone else.

In this kind of situation, you're not going to run "h2xs" for every module that you write. If you're developing inside a structure like this:

  ~/dev/Modular-Stuff/
         Changes
         MANIFEST
         Makefile.PL
         Makefile
         README
         lib/
           Modular/
             Stuff.pm
         t/
            Modular-Stuff.t

It just seems like there are too many annoyances in the way. Do you have to do a "make install" to test this module in context? Or maybe you need to add ~/dev/Modular-Stuff/lib/ to the front of your PERL5LIB so that the development version of the module is seen by perl? And what do you check-in to version control, ~/dev/Modular-Stuff/lib/Modular/Stuff.pm, or the installed version? The developer would probably want to check-in the development location along with the t/*.t files, but the site maintainers would probably prefer the installed version be checked in for branching/tagging purposes. I suppose you could try checking in both, but that sounds pretty scary.

The ways people really do it would be interesting to hear about (just as an example: is there any standard at all outside of the h2xs world about where to put test files and what to name them?

I often find myself with a hierarchy of test classes that I put in t/lib that mirrors the files in lib/. Funny, I never like the idea of mirroring trees like that. It seems inelegant to me to have to create a chaing of several directories when you already have them right next door.

But then it's not like I can't use structures like this if someone else makes that design decision (e.g. Mason works that way). It's probably just a personal preference on my part.