Re^3: Redesigning distribution with Module::Starter

I think all those maintenance tasks are outside of what Module::Starter purports to do.

Just as an example, here's how I do these things:

Test files don't need to know the module names besides their functionality, so changing the module name/splitting a module name will obviously also need editing the test. But most likely this also comes with a change in the API, so something more needs to change anyway.
If a test file really needs to know about the name of the (main) module, I have that test load my Makefile.PL, which can provide that information through a function.
I don't know why updating POD files would be a problem, but then I only use POD files for documentation that has no additional code. All other documentation lives in the .pm file itself and gets updated by me writing that.
Updating the version number of a distribution is a job for perl-reversion in Perl::Version.
Updating the MANIFEST file is done by make manifest.
Updating the META.* files is done by make distmeta.

There are other approaches, for example I don't know how Module::Build-based distributions manage these files.

There are Dist::Zilla and Dist::Minilla, which also allow you to manage a distribution, but I dislike them as for supplying a patch or running the test suite on a Git checkout of such a module, you also need to install the same distribution builder and all the plugins that the author has used for this distribution.

Comment on Re^3: Redesigning distribution with Module::Starter Select or Download Code

Replies are listed 'Best First'.
Re^4: Redesigning distribution with Module::Starter by haj (Vicar) on Aug 23, 2018 at 14:48 UTC
Corion: There are Dist::Zilla and Dist::Minilla, which also allow you to manage a distribution, but I dislike them as for supplying a patch or running the test suite on a Git checkout of such a module, you also need to install the same distribution builder and all the plugins that the author has used for this distribution. Installing the plugins can be avoided if the `Makefile.PL` (or `Build.PL`) created by the tools is included in the Git repository, and I seem to recall that this practice has been recommended in dzil circles. Also, it should be possible to run the tests with `prove`. While participating in the CPAN Pull Request Challenge I've seen modules with insane plugin lists which I did not want to install, but `prove` was fully sufficient. I myself was reluctant to use Dist::* for a long time, but mostly because of the guesswork needed to figure out which plugin does what, how they can be configured and how they interact with each other. The documentation is often extremely short. Eventually I found that the benefits of skeletons and different profiles (e.g. for Moose / non-Moose boilerplate) outweigh the learning curve and am now using `Dist::Zilla` - with a minimal list of plugins.	[reply]
Re^4: Redesigning distribution with Module::Starter by LanX (Saint) on Aug 23, 2018 at 14:57 UTC
The POD normally mirrors the version number, does Perl::Version help to update this too? And I prefer to have the usage information and licence inside separate Module.pod file. The POD inside the the .pm will be used to generate the .pod, but will also contain information relevant for the maintainer . Like having a =head1 for `Exported` or `Methods` which will be shown in the Module.pod, while documentation for `=head1 Internal` subs are hidden. Much saner, I don't need repeated informations and boilerplate when looking into code. And refactoring becomes easier. > Test files don't need to know the module names I'm not sure how you unit test a sub-module without `use` -ing it.° Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice} update Furthermore there is plenty of code in POD which should be tested too. Like from Synopsis, Examples and Tutorials. °) you mean `prove -M` ?	[reply] [d/l] [select]
Re^4: Redesigning distribution with Module::Starter by LanX (Saint) on Jul 21, 2020 at 18:47 UTC
> Test files don't need to know the module names besides their functionality could you please elaborate how this is done? especially if I need to specify import options? Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^5: Redesigning distribution with Module::Starter by Corion (Patriarch) on Jul 21, 2020 at 20:29 UTC
My author tests load `Makfile.PL` and call the function `get_module_data()` from it (well, `main::get_module_data()`), which returns the hash used to initialize ExtUtils::MakeMaker. From there, they can find the "main" module name if such is needed. The module specific tests `use` the module, but I'm not sure where Module::Starter comes into play with tests specific to a single module.	[reply] [d/l] [select]

update