chromatic wrote:
On Monday 30 January 2006 20:40, Adam Kennedy wrote:
Incremental releasing is a toolchain problem.
Having to rerelease more than one module and making every one of my users
upgrade every module that uses this tool -- not just my one or more modules
-- rather than making every one who uses the tool upgrade just the tool is a
bigger problem.
I might be missing something here, but the math for the "Oh no, there's a
problem in the tool" doesn't seem to favor Module::Install. If there's a
problem in the build tool:
With Module::Build or MakeMaker:
- either (Ken and Randy) or Schwern have to upload a new version to the
CPAN
- everyone who wants to get the bugfix has to install the new version, once
per installation
(cut/paste)
> Now I know you and Ingy and Audrey and Jesse are all very smart, so
> am I completely misunderstanding things?
(cut/paste)
To answer that question, the bit you missed is here.
Why would any client get the bugfixed version? Nothing else they use is
explicitly saying they need it, so the CPAN(PLUS) client wouldn't bother
to install a new version.
The only 2 ways for them to get it is to either start doing incremental
releases of lots of other modules that explicitly up their dep on it. In
fact, because people are going to have old versions of the module around
for years, you really do need to release an incremental of everything
that uses EUMM/MB to up the dependency in order to be 100% sure. (note,
that's for 100%, for less things aren't that bad)
The second way is for the user to spot there's a problem somewhere in
the 300 pages of CPAN output, diagnose the problem, research the
problem, find the answer "update your Module::Build", and upgrade it
once per installation.
Unless of course they use a packaging system (PPM/deb/RPM) in which case
they won't be hit by the problem.
There isn't really any very good way (that I can see at least) to ensure
that an end-user gets an update to EUMM/MB, just the module packager.
With Module::Install:
- you or Ingy or Audrey have to upload a new version to the CPAN
- everyone who wants to get the bugfix has to install the new version, once
per installation
That should read once per CPAN author. Normal users do not ever need to
install the actual Module::Install dist. Only module authors.
- everyone who wants to use the bugfixed version has to release a new version
of each module that uses it
Yes, in the "oh fuck we broke everything" scenario, all most authors are
forced to increment. This is a big downside. In the Cygwin case for
example, a bunch of authors won't care and won't increment immediately,
because their userbase is doing just fine. And then when they do their
next normal release, the upgraded Module::Install comes along for the ride.
- everyone who wants to use the buildbugfixed version of each new module has
to install each distribution, once per installation
Yes, but they install the module that threw the error, not an unnamed
dependency somewhere down the chain.
Unless of course they use a packaging system (PPM/deb/RPM) in which case
they won't be hit by the problem either, just the module packager.
I don't say this often, but that really doesn't seem scalable to me. If I
have to re-release a distribution because of a bug in the build system that
users can't upgrade on their own, the build system sucks for my purposes.
I guess the best difference in attitude I can provide is this one
(without declaring either a clear and obvious winner in all cases)
EUMM/MB's response to a worst-case scenario optimises for smart users,
minimizes the work for the author, and allows the problem to dissipate
over time (spread across all dists)
MI's response to a worst-case scenario optimizes for stupid users, or
robot users, creates more work for the authors, but allows the problem
to be fixed immediately for each dist on all platforms.
So, MI simplifies and saves time when writing installers, and makes
certain the solution to a problem is propogated to 100% of all users.
Certainly this does come at some cost to the author, particularly in a
worst-case scenario.
Of course, in other scenarios such as problems related to particular
user subsets, or where there are small ordinary improvements, there will
be different behaviours by both.
WRT to all of this, all I can say is that just like Module::Build,
Module::Install is not at 1.00 yet, and so is not recommended for
widespread (i.e. all modules) use.
There are still some nigglies being worked out of both MB and MI (the MB
PREFIX problem, and the MI cygwin problem for example). However an
individual MI author doesn't ever need to worry about hitting old broken
versions on some machines. A MI dist can install in most cases on a
default Perl 5.005 straight out the box.
I leave it to the MB author to make recommendations for adoption there,
but for MI my personal recommendation would be.
1. If Makefile.PL works just fine and does everything, don't move. None
of the replacements are at 1.0 yet.
2. If you need more than the bog standard Makefile.PL but what you want
it relatively common, and MI provides it in a single common, use MI. And
make sure to do a quick upgrade of MI whenever you do a new release so
any small fixes get upgraded.
3. If you need to do crazy custom subclassing stuff, then both MI and MB
can do it, although MI's custom stuff might not be tested as well.
As for when I'd expect people to start adopting MI, do it after 1.00.
Presumably by then we will have done exhaustive testing to make sure
there aren't any worst-case scenarios left in the code.
Then there's not going to be any issues with incrementing vast numbers
of modules.
*gasp*
Adam K
