Dallaylaen has asked for the wisdom of the Perl Monks concerning the following question:

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?

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.

  • Comment on Multiple CPAN distributions under the same git repository?

Replies are listed 'Best First'.
Re: Multiple CPAN distributions under the same git repository?
by choroba (Cardinal) on Nov 12, 2018 at 10:18 UTC
    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

    [download]

    so I can run commands like 

    ./forall git fetch upstream

    [download]

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

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,

    [download]
[reply]
[d/l]
[select]

      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.

[reply]
Re: Multiple CPAN distributions under the same git repository?
by jimpudar (Pilgrim) on Nov 12, 2018 at 20:27 UTC

    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

    πάντων χρημάτων μέτρον έστιν άνθρωπος.

[reply]

      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...

[reply]
Re: Multiple CPAN distributions under the same git repository?
by dpchrist (Initiate) on Nov 21, 2018 at 23:33 UTC

    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).

[reply]

Back to Seekers of Perl Wisdom