Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: non-CPAN module distributions

by perrin (Chancellor)
on Sep 16, 2003 at 19:23 UTC ( #291933=note: print w/replies, xml ) Need Help??


in reply to non-CPAN module distributions

Is this a bad approach? Would it be better to just keep using the source module files (*.pm) directly without modulizing them, and just come up with some way to handle unit tests, rather than use the h2xs-generated framework?

Yes. You have nothing to gain by making separate installations unless you intend to use these modules in separate places. I don't really understand the problem with the unit tests. You can make as many tests as you want and they can test anything you want. I have a whole bunch of different test files in my current project, all testing different modules, and they all just sit in my t/ directory.

what is a good way to determine which version of each module is currently installed on a system?

Add a $VERSION variable to each module.

what is a good way to handle the build process so that only those modules that have been modified are rebuilt? I can do a CVS update of the module sources on each system, but I need some way to determine which modules need to be re-built and re-installed.

This is an example of why you shouldn't split these up. Your global Makefile idea would probably work though.

Replies are listed 'Best First'.
Re^2: non-CPAN module distributions
by adrianh (Chancellor) on Sep 16, 2003 at 21:13 UTC
    You have nothing to gain by making separate installations unless you intend to use these modules in separate places.

    Hmm. I sometimes develop in this way. You do get some useful things from this model:

    • You can easily separate the test scripts that apply to this particular module from those that apply to another. This allows you to easily run only the relevant tests when testing a module. This can save time and make TDD considerably more pleasant.
    • People can work on modules independently from each other.
    • It can give you a nice clear separation of unit tests (distributed with module directory) and acceptance tests (distributed with application as a whole).
    • Allows you to easily release module updates rather than application updates as appropriate.

    There are certainly other ways of getting these benefits, but the CPAN-ish structure gets you a lot without any effort.

      I think you can do all of these things just by making separate test scripts for each module and only running the one that pertains to the module you're working on. That's what I'm doing now.

        Having a single test script per module is not always practical.

        Also I find having people work independently is harder if you keep everything bundled together. With separate distributions you can check individual modules in and out, only update single modules, avoid name clashes with test scripts from other modules, document prerequisites on a module-by-module basis, etc.

        There are certainly other ways of getting the same sort of functionality - but I don't see that having multiple module directories has any major disadvantages.

Re: Re: non-CPAN module distributions
by mp (Deacon) on Sep 16, 2003 at 21:11 UTC
    Perrin, thank you for your input.

    The advantages I see of moving groups of module files (*.pm) into module distributions are that tests would be bundled with the code they are testing, support libraries needed just during testing would be bundled in as well, and in many cases, only one or two module distributions would be required for standalone development and unit testing. It seems to me that it would be easier to have someone work on and test just one module distribution without having to understand the entire design and interactions between it and other modules.

    It may well be that these advantages are outweighed by the disadvantages -- that is part of the assessement I'm currently trying to make before going very far down this path. Some disadvantages of this bundling into module distributions are that later code restructuring will become more difficult, and that additional work is needed at the very least, to setup the framework for doing module installations.

      The advantages I see of moving groups of module files (*.pm) into module distributions are that tests would be bundled with the code they are testing

      If you have a single big bundle, the tests are still bundled with the code they are testing.

      support libraries needed just during testing would be bundled in as well

      I don't see why these couldn't be part of your big bundle as well.

      in many cases, only one or two module distributions would be required for standalone development and unit testing.

      Does it hurt anything to have the other modules there if they aren't being used?

      It seems to me that it would be easier to have someone work on and test just one module distribution without having to understand the entire design and interactions between it and other modules.

      Why is this difficult to do when they're all together? I have lots of modules as part of one project with no separate installs. Each one has a separate test script. The tested modules don't interact with each other at all during tests unless it's really necessary. While working on one module, I just run that module's test. When I'm ready for integration testing, I run all the tests. If you split up your modules, integration testing will be a lot more hassle.

      You can split them up if you want to, but I just don't think you'll get much value from it, unless you plan to release individual pieces to CPAN.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://291933]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (2)
As of 2022-05-28 07:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (98 votes). Check out past polls.

    Notices?