Time for a new Module::Build release manager
David Golden
June, 2009. Here are some highlights of what has happened since then:
* Over 60 Module::Build tarballs -- most of them development
releases, admittedly
* Converted the Module::Build from Subversion to Git, attracting a
half-dozen or so new contributors
* Rigorous triage of the M::B RT queue -- every ticket was reviewed
to set the right severity and status
* About 70 RT tickets noted in Changes
* Updated release documentation and blead patching documentation
Since then, my own use of Module::Build has declined, as much of my
need for it as an author has been replaced by Dist::Zilla toolkit. At
the same time, I've taken on additional responsibilities with P5P,
CPAN PAUSE administration, and other parts of the toolchain.
Therefore, with the release of 0.3800, I am retiring as Module::Build
release manager. I will continue to contribute occasional patches,
particularly relating to any bugs uncovered in the new CPAN Meta Spec
v2 support added in 0.3800, but do not plan to release any more
tarballs to CPAN, short of a major flaw in 0.3800 requiring an
emergency fix.
I encourage interested parties to speak up and volunteer to take on
the release manager role.
Regards,
David Golden
Leon Timmermans
> Since then, my own use of Module::Build has declined, as much of my
> need for it as an author has been replaced by Dist::Zilla toolkit. At
> the same time, I've taken on additional responsibilities with P5P,
> CPAN PAUSE administration, and other parts of the toolchain.
>
> Therefore, with the release of 0.3800, I am retiring as Module::Build
> release manager. I will continue to contribute occasional patches,
> particularly relating to any bugs uncovered in the new CPAN Meta Spec
> v2 support added in 0.3800, but do not plan to release any more
> tarballs to CPAN, short of a major flaw in 0.3800 requiring an
> emergency fix.
>
> I encourage interested parties to speak up and volunteer to take on
> the release manager role.
I'm not particularly interested in improving Module::Build. I am very
much interested in cannibalizing pieces of its code to make them
reusable for the second generation of Build.PL builders, which will
hopefully obsolete Module::Build in the future. Depending on your
point of view this would make me either the worst or best possible
candidate to manage Module::Build. In either case I do not think I
would be doing it for more than just a handful of releases though.
Leon
Alberto Simões
On 07/03/2011 19:34, John M. Gamble wrote:
> Well ... this raises a question. Whither Module::Build?
>
> Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
> up as a Dist::Zilla::Simple?
AFAIK Dist::Zilla is NOT a substitute to Module::Build (or
ExtUtils::MakeMaker).
--
Alberto Simoes
CCTC-UM / CEHUM
John M. Gamble
Well ... this raises a question. Whither Module::Build?
Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
up as a Dist::Zilla::Simple?
I'm on this list because once I found out about Module::Build, I transferred
my modules over to it as fast as my little fingers could edit them, and I
wanted to learn more as it developed. I like it, it was and is a much easier
system to use, and if it doesn't have an independent future I'd like to see
it become a bridge to an even easier system, not simply broken apart.
-john
Marvin Humphrey
> Well ... this raises a question. Whither Module::Build?
How about maintenance mode? Does Module::Build really need to be aggressively
developed?
Module::Build provides a fantastic improvement over MakeMaker: it allows us to
write build actions in pure Perl. And it has matured into a build system with
a lot of nice features.
M::B wasn't core and had some bugs at first, so I could understand when people
got impatient over it back in 2006. But it's been distributed with core Perl
for years now and it's pretty darn stable.
In a quick glance at Dist::Zilla, I see that it does stuff like incorporate
POD::Weaver so that they can write their docs in a new language that extends
POD - <http://dzil.org/tutorial/writing-docs.html>. That's cool, and I love
to see people pushing the envelope, but it's not a feature I'd want to
use. I just want to write my elaborate build scripts in Perl rather than
Make.
If nobody steps up and wants to maintain M::B within the confines of its
current API, does it make sense to declare victory and remove it from
dual-life status?
Marvin Humphrey
Jonas B. Nielsen
Your work and contributions have been and are much appreciated. It will most certainly be a challenge to live up to you and your tireless efforts and they will be missed. I am however very happy to hear than you will continue your work in other parts of the Perl toolchain.
Thank you! from a long time Module::Build user,
jonasbn
David Golden
That's correct. Dist::Zilla is a distribution packaging tool only.
It *can* create a Makefile.PL or Build.PL for you (and most
Dist::Zilla authors seem to do that) but your distribution still
relies on EU::MM or M::B for the configure/make/test/install cycle for
end-users.
I wrote a little about which tools I think people should use here:
http://www.dagolden.com/index.php/1173/what-tools-should-you-use-to-create-a-cpan-distribution/
I think M::B still has a role for customized distribution needs.
-- David
Adam Kennedy
> Dist::Zilla is the first attempt to separate the authoring role from the
> installing role that's achieved significant traction. As such, it will
> never replace the "installing" side of MakeMaker or MB. There's been
> some talk about an "Install::Zilla" to implement the installing role,
> but AFAIK nobody's started working on that yet.
*AHEM* Module::Install *COUGH*
While M:I may be about 30% evil, it does essentially the same thing,
detaching a small subset of itself (the non-Admin classes) and
bundling them as the ::Installer half of itself.
You're in crufty I-Didn't-Write-This-Stuff-I-Just-Maintain-It'ship
Adam K
Adam Kennedy
written for a world where you don't have configure-time dependencies.
Thus the trend to large and involved single packages with everything
included, just as things like CGI.pm were before it in the days when
we didn't have any dependencies at all.
Once a CPAN with configure_requires becomes the toolchain
back-compatibility target the age of the large self-contained build
system will come to an end, and you'll see a trend to more diverse,
dynamic and componentised build systems.
This is largely inevitable, and Leon just represents the leading edge
of this change.
Adam K
Adam Kennedy
an install-time only wrapper and an author-time only wrapper.
It just happens that as an author installing Module::Install you get
both layers installed, and the two layers switch intelligently so that
the same "requires" command could dispatch to two different functions
for installers and authors.
Adam K
On 10 March 2011 07:09, Christopher J. Madsen <pe...@cjmweb.net> wrote:
> I don't think I understand your point. I've never used Module::Install,
> but I thought it was basically just a wrapper around MakeMaker.
>
> By "Install::Zilla" I mean a Module::Build-like tool, but one that has
> no support for the authoring role. It wouldn't bundle itself into
> dists; it would just use configure_requires along with a Build.PL that
> said "use Install::Zilla" instead of "use Module::Build". It wouldn't
> be tightly coupled to Dist::Zilla.
>
>
> I've thought of another way to split Module::Build into separate dists
> for installing and authoring that may work better than my first proposal.
>
> Module-Build would become the installer-only dist. The authoring-type
> actions would be replaced with stubs that tried to load
> Module::Build::Authoring and redispatch to that. If
> Module::Build::Authoring was not installed, the stub would print a
> message saying that you need to install it from CPAN in order to run
> that command.
>
> --
> Chris Madsen pe...@cjmweb.net
> -------------------- http://www.cjmweb.net --------------------
>
>
Leon Timmermans
> By "Install::Zilla" I mean a Module::Build-like tool, but one that has
> no support for the authoring role. It wouldn't bundle itself into
> dists; it would just use configure_requires along with a Build.PL that
> said "use Install::Zilla" instead of "use Module::Build". It wouldn't
> be tightly coupled to Dist::Zilla.
See http://blogs.perl.org/users/leon_timmermans/2011/03/le-roi-est-mort-vive-le-roi.html
for my ideas on that. Actually writing that module builder is not my
first or most important goal (though it will be the one most visible
to end-users). My primary goal is to make writing a module builder
easy (or at least a lot easier than it is now). Currently there is a
fairly large amount of accidental complexity in writing a Build.PL
implementation. Those problems should have modules solving them,
preferably refactored from well-tested Module::Build code.
Leon
Nicholas Clark
I don't think I'd use the word "victory" for that.
"remove it from dual-life status is ambiguous"
We've now got the core perl laid out in git such that
modules in cpan/ are dual life, and the master repository is somewhere else
generally we're not tracking that repository. We're merging CPAN releases
modules in dist/ are dual life, the core git repository is master, but someone
is prepared to (and does) make release of them to CPAN, which will (to some
degree) support earlier versions of perl
modules in ext/ are only shipped with the core perl
A side effect of being in ext/ is that you can only upgrade a module there
by upgrading your entire perl.
Now, if no-one wants to volunteer to actually make CPAN releases of
Module::Build, then
a: in the short term cpan/Module-Build is going to be 100% stable
b: in the medium term, if upstream is dead, and there are bugs to be fixed,
it will be moved to signify that the perl core is upstream
If *no-one* wants to volunteer to make the CPAN releases, then logically it
will be moved to ext/
At which point, if you hit a bug in Module::Build, your next fix comes by
upgrading perl.
I'm sure this is going to make some people scream.
Sorry folks, that's how it is.
Volunteer, find someone to volunteer, pay someone to "volunteer", or shut up.
Nicholas Clark