ADAMK::Release - Halfway between SVN and GitHub
When it comes to repository structure, my philosophy has always been that you should have as few files as possible with as little redundant information as possible, but all files that are in the repository should end up in the final tarball, and all content be identical to what ends up in the final tarball.
This is very different from Dist::Zilla, which has an extra config file and content that has POD with template content in it.
When you look after a few hundred modules, the less files you have to edit or save the better.
But I recognise this approach isn't for everyone, so I've never encouraged others to follow my practices, and I've never packaged my scripts up into a module. Until now.
As my modules move into GitHub they inherit this legacy of this minimal files approach, at least in the short term until I start changing over the distribution structure to a more conventional style.
To bridge this gap, should anyone else want to try and build one of my new GitHub distributions, I've uploaded ADAMK::Release.
This contains a script adamk-release which can be used to build and distribution from my repository using the following syntax.
adamk-release Module::Name
The approach it uses it to pull a fresh export from the repository, parses the files for information such as the license, copyright date, version etc, checks a number of different issues, and generates all of the other files for the repository.
It then applies some cleaning steps, such as correcting any newlines to match the local unix newlines, and touching all files to freshen their timestamps and prevent some edge cases where files can sometimes end up appearing to be from the future (breaking installs horribly on Unix).
Finally it builds and runs the module tests several times, including running them as root to ensure that filesystem-related modules will install properly should the install process be run as root (vs running as a regular user).
I'm not entirely sure that it is building modules correctly yet, but it should provide a good bridge in the short term and allow other people to make releases directly from my repository if they need to.
I blog about Perl.
Minor quibble:
> This is very different from Dist::Zilla, which has an extra config file and content that has POD with template content in it.
This is different from *some Dist::Zilla configurations*, but it is quite possible to achieve your goals with Dist::Zilla. Indeed, Dist::Milla (essentially a stock minimalist dzil configuration) meets these goals.
If you don't like modifying your .pm files between the repository and the shipped version, you don't have to! You don't have to use [PodWeaver], [PkgVersion], [Authority] or the other plugins that modify your source files.
Personally, I treat Dist::Zilla like a compiler - it transforms the *meat* of my distribution (code, tests and documentation) into something that is shippable (including installers, META.*, release tests). These things can be automatically generated from the meat, so I find it repetitious (as well as violating the "lazy" tenet) to include those directly in the repository.
> When you look after a few hundred modules, the less files you have to edit or save the better.
Exactly! :)