Multiple CPAN distributions under the same git repository?

[Dallaylaen]

Hello dear esteemed monks,

Suppose I have several similar and small modules (actually plugins for another module) and I'm looking for a way to keep them in git.

The plugins are not expected to be changed often. When they are, however, many of them may require an almost identical change (e.g. the main module adds a new feature or fixes a bug).

So what are the ways to achieve it?

• (1) Just make a repository per module. Pros: it's simple. Cons: lots of jumping through hoops in a mass update situation.
• (2) Make a package named My::Module::Plugins and bundle them all. Pros: it's simple. Cons: I want my users to be able to pick which dependencies they need.
• (3)Have several directories in one repository. Pros: Can modify and build them at once. No need to keep an eye on many repos. Cons: it's complicated. The directory structure itself needs maintenance.

What are the examples on CPAN? So far I've been able to peek at Map::Tube::* which uses the first approach. But maybe there are others? What do they use?

Thank you.

[choroba]

I haven't been in such a situation, but I guess I'd go with (1). To avoid lots of jumping through hoops, I'd try to script most of the steps. For example, at work, we have lots of repositories, so I keep them all in one directory that also contains a simple shell script called forall:

#!/bin/bash
orange=$'\e[33m'
off=$'\e[0m'


for project in */ ; do
    [[ -d "$project"/.git ]] || continue
    (
    cd "$project"
    echo "$orange$project$off" >&2
    "$@"
    )
done

so I can run commands like

./forall git fetch upstream

So, you'd fix the code of each repository, and than just run a script to run all the tests, prepare distributions, etc.

[Dallaylaen]

Thank you.

I just realized what I don't like about approach (1), which is superior in every other aspect.

For modules' author there's virtually no difference between the three approaches. One way or another, it's going to get scripted.

However, as a side contributor, I would prefer to know there's more than just one module. Is my bug specific to just one plugin? Am I changing some boilerplate and/or generated code? Is this change compatible with the author's tooling? And the answer to all of these is just ls.

That said, I'm not sure whether it's just me, or there are others who feel that way.

[jimpudar]

Honestly, having to make identical changes in multiple places is a code smell.

If you are adhering to the DRY (Don't Repeat Yourself) principle, you shouldn't need to do things like this.

Of course in the real world, this isn't always so easy to accomplish :)

Best,

Jim

[Dallaylaen]

In my particular case (main module + many plugins), having no repetitive changes implies that (1) API is very stable, (2) extending the module requires little to no boilerplate, and (3) writing tests for the module requires little to no boilerplate.

And having that level of design skills implies posting to p5p rather than SoPW :)

EDIT: From Wikipedia:

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.

And, yes, the repetition in plugins indicates a deeper problem with my code, which is: I cannot design a succinct, feature-rich, and testable module interface in one go. And while I'm solving that problem, I'd rather have my imperfect code nicely organized, which is why I'm asking...

[dpchrist]

I have always favored a one-to-one mapping between Perl distributions and version control system (VCS) projects.

Multiple distributions inside one VCS project might sound appealing for a tightly-integrated set of distributions, but I suspect could lead to problems later. If and when I feel the urge to combine distributions, I make one distribution (in one VCS project).

Splitting one distribution into pieces and putting each into different a VCS project sounds like a recipe for disaster. If and when I feel the urge to split a distribution, I make multiple distributions (each in its own VCS project).

Most platforms running Perl today have plenty of disk space. Unless your modules are for old computers or small embedded platforms, I would put them all into one distribution (in one VCS project).