Diab Jerius
2014-09-10 14:23:56 UTC
A few days ago I was briefly stymied by the inability to perform a
clean install of PDL 2.007 from CPAN, due to a recent release of
Module::Compile missing a dependency on Module::Install
(https://github.com/ingydotnet/module-compile-pm/issues/1).
Last night Jeffrey Thalhammer remotely gave a talk about Stratopan at
the boston.pm meeting which inspired me to think about how we could
solve problems like this.
For those not familiar with Stratopan, it's essentially a cloud based
Pinto repository. Pinto is a tool for maintaining independent,
version controlled, subsets of CPAN. As far as CPAN clients are
concerned, Stratopan looks just like CPAN, just with a different URL,
and, importantly, with a curated set of known good dependencies.
How does this fit in with PDL? As with any large codebase, PDL
depends upon various CPAN modules; installation from CPAN is subject
to whatever the current state of those modules on CPAN. In this case,
that state is broken. What Stratopan offers is the ability to tell
users,
Point your cpan client at our Stratopan repository,
and we'll guarantee that you'll be able to install PDL.
We'd no longer be at the mercy of CPAN breakage.
My suggestion is that we create an official PDL repository on
Stratopan. When a formal production release is cut, a set of "known
good" dependencies would be established as a Pinto stack (essentially
a branch) on Stratopan. If need be, patched versions of modules could
be installed there. Installation instructions could point to that
stack as an alternative to CPAN.
CPAN would of course continue to be used as a testbed for development
releases (and for those who don't mind fixing things when they break).
Over the years I've dealt with similar issues with CPAN modules using
the distroprefs functionality in CPAN.pm, which can automatically
patch modules pulled from CPAN. Unfortunately this requires somewhat
obscure knowledge about CPAN.pm's workings, and more importantly,
isn't supported by cpanm.
Stratopan isn't a panacea, of course. There will always be ways of
breaking PDL after a clean install using it. For example, there's
still the chance that the user may update a dependency from CPAN which
introduces new run-time behavior which breaks PDL. We could, however,
promise that if PDL is installed into it's own local lib, with known
good dependencies, that that will always work in isolation from
whatever else the user does with their Perl environment.
Diab
clean install of PDL 2.007 from CPAN, due to a recent release of
Module::Compile missing a dependency on Module::Install
(https://github.com/ingydotnet/module-compile-pm/issues/1).
Last night Jeffrey Thalhammer remotely gave a talk about Stratopan at
the boston.pm meeting which inspired me to think about how we could
solve problems like this.
For those not familiar with Stratopan, it's essentially a cloud based
Pinto repository. Pinto is a tool for maintaining independent,
version controlled, subsets of CPAN. As far as CPAN clients are
concerned, Stratopan looks just like CPAN, just with a different URL,
and, importantly, with a curated set of known good dependencies.
How does this fit in with PDL? As with any large codebase, PDL
depends upon various CPAN modules; installation from CPAN is subject
to whatever the current state of those modules on CPAN. In this case,
that state is broken. What Stratopan offers is the ability to tell
users,
Point your cpan client at our Stratopan repository,
and we'll guarantee that you'll be able to install PDL.
We'd no longer be at the mercy of CPAN breakage.
My suggestion is that we create an official PDL repository on
Stratopan. When a formal production release is cut, a set of "known
good" dependencies would be established as a Pinto stack (essentially
a branch) on Stratopan. If need be, patched versions of modules could
be installed there. Installation instructions could point to that
stack as an alternative to CPAN.
CPAN would of course continue to be used as a testbed for development
releases (and for those who don't mind fixing things when they break).
Over the years I've dealt with similar issues with CPAN modules using
the distroprefs functionality in CPAN.pm, which can automatically
patch modules pulled from CPAN. Unfortunately this requires somewhat
obscure knowledge about CPAN.pm's workings, and more importantly,
isn't supported by cpanm.
Stratopan isn't a panacea, of course. There will always be ways of
breaking PDL after a clean install using it. For example, there's
still the chance that the user may update a dependency from CPAN which
introduces new run-time behavior which breaks PDL. We could, however,
promise that if PDL is installed into it's own local lib, with known
good dependencies, that that will always work in isolation from
whatever else the user does with their Perl environment.
Diab