Could not open 'lib/Gzip/Libdeflate.pod': No such file or directory

[szabgab]

After cloning the repo I ran perl Makefile.PL and got the above error

I see there is a file called lib/Gzip/Libdeflate.pod.tmpl

[szabgab]

I tried to run perl make-pod.pl but it complains about Perl::Build::Pod missing and I could not install that module.

[szabgab]

Even if one manages to install Perl::Build::Pod the make-pod.pl then need Deploy.pm and I don't know where does that come from.

[benkasminbullock]

I have added various generated files to the repository in the following commit: 077f9fc You should be able to edit it now.

(This module "Perl::Build::Pod" is not related to the module which is on CPAN called "Perl::Build". That module actually came after I made a non-CPAN build module called "Perl::Build" and started using it and then by some coincidence that user (Tokuhirom?) used exactly the same name for his module.)

[szabgab]

Thanks. I don't think that adding generated files to the repo is a good idea. IMHO it would be better to make the tools needed for the generation available to the public. Even if they are in a separate public repository and not released to CPAN.
That way the generation would be reproducible by any potential contributor.

And probably it would be a good idea to rename your private module so it won't have the name as the public module. Even if that came later.

[benkasminbullock]

There is a name clash with the existing module Perl::Build as noted above. Up until now I have had very few contributions to my Perl CPAN modules so it has hardly been a problem. This set of things was on github but I deleted it.

I will consider making it available but I'm not sure what you want to do with this repository so it's a bit dubious about making it available right now. Could you explain what you are planning to do? Thank you.

[szabgab]

My goal is to make it easy for others to contribute to every CPAN module. I think having a working CI with all the pieces in public will help to do that too.

Imagine one day you stop caring about this package, but you still want to keep the opportunity for others to pick it up and start maintaining it. It is quite unlikely that at that point of time you'll have the free time and energy to publish all the pieces that were private earlier. So it is better to do it now.

You can see my experiments to set up CI here: https://github.com/szabgab/gzip-libdeflate/actions

[benkasminbullock]

I understand your concerns about this module. At the moment the quickest thing to do is to add the constructed files to the repository. Prior to this I did make some effort to make all these things available, and it turned into a rather annoying situation for me, which is why I removed them again. But yes it would be better to make all of it available. The big nuisance for me is that Tokuhirom used the name "Perl::Build" for a completely unrelated module, so I have to now go back and rename everything to avoid confusion with that module. Since my "Perl::Build" predated his one I have a nagging suspicion that the name choice was not a coincidence. I should not be suspicious I suppose but it is a real nuisance for me having to rename everything.

[szabgab]

That sounds annoying.
Maybe put your module back to github and send out a call for help to rename it. If you do it now you can grant hacktoberfest bits to the people who help you with good pull-requests.

[ap]

FWIW perlmodlib suggests:

If developing modules for private internal or project specific use, that will never be released to the public, then you should ensure that their names will not clash with any future public module. You can do this either by using the reserved Local::* category or by using a category name that includes an underscore like Foo_Corp::*.

That’s clunky of course so personally I have tended to instead use names without :: for modules not intended for CPAN (e.g. calling the module PerlBuild, in this case).

Since my "Perl::Build" predated his one I have a nagging suspicion that the name choice was not a coincidence.

I very much doubt it. Given what his Perl::Build does, the name he picked is not exactly a stretch. If your module was not on CPAN then he likely wasn’t aware it clashed with anything.

Prior to this I did make some effort to make all these things available, and it turned into a rather annoying situation for me

Yeah, properly dealing with personal tooling and keeping that updated is somewhat painful. Dist::Zilla has the most traction in this space but it’s frankly not much less contributor-hostile than your approach (and far more anti-reproducible, probably), it’s just “standard”, so you don’t get yelled at for using it.