Re: Re: non-CPAN module distributions

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.

Comment on Re: Re: non-CPAN module distributions

Replies are listed 'Best First'.
Re: Re: Re: non-CPAN module distributions by perrin (Chancellor) on Sep 16, 2003 at 21:57 UTC
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.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: non-CPAN module distributions
by perrin (Chancellor) on Sep 16, 2003 at 21:57 UTC

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.

[reply]