2008Q2 Grant Proposal - Automatic INSTALL generation
Thu, 01-May-2008 by
Alberto Simões
edit post
<![CDATA[
* **Name:** Michael G Schwern
* **Project Title:** Automatic INSTALL.txt generation
* **Synopsis:** Write a module which can automatically generate Perl module installation instructions. Integrate into Module::Build and ExtUtils::MakeMaker.
**Name:**
Michael G Schwern
**Project Title:**
Automatic INSTALL.txt generation
**Synopsis:**
Write a module which can automatically generate Perl module installation instructions. Integrate into Module::Build and ExtUtils::MakeMaker.
**Benefits to the Perl Community**
Most Perl modules come without module installation instructions. At most they might include the "make" mantra. Figuring out how to install a module, its prerequisites and how to get it to install into a different location than the system directory can be daunting to a newbie.
By making the generation of an accurate INSTALL.txt for modules simple and easy for authors, more modules will include installation instructions and Perl modules will be easier to install.
This makes CPAN modules more accessable, helping with a user through the first ten minutes of trying to use CPAN modules.
**Deliverables**
First stage is to write a prototype module which can do the following...
* Write a module which, when run inside a distribution directory, can write a file containing...
* The appropriate basic make or Build instructions.
* Instructions for installing into the user's home directory
* Include reference to PERL5LIB and "use lib"
* Necessary module prerequisites
* If a C compiler is necessary
* If make is necessary
* Minimum version of perl (if specified)
* Contact and bug tracking information (if available)
Then add support for this to MakeMaker and Module::Build.
* Add a create_install() option to Module::Build similar to create_readme().
* Add a CREATE_INSTALL option to MakeMaker.
NOTE: It may be easier to skip the independent module and simply code it as part of Module::Build and then port to MakeMaker. This is because a lot of the information which the prototype will have to probe for may already be known by Module::Build.
**Project Details**
Many moons ago I wrote a program to do this called mod2readme. http://schwern.org/~schwern/src/mod2readme
**Project Schedule**
I am available to begin work after June 20th. This is a straightforward, low risk project using technologies I know well.
* First alpha release: Two weeks after start.
* Stable integration with Module::Build: Two weeks after first alpha.
* Stable integration with MakeMaker: One month after first alpha.
Everything takes longer with MakeMaker.
If the project starts June 20th, then the schedule looks like this:
* First alpha release: Beginning of July
* Stable integration with Module::Build: Mid July
* Stable integration with MakeMaker: Mid August
The project is considered complete when the deliverables have been integrated into Module::Build's and MakeMaker's trunk.
**Bio**
I maintain ExtUtils::MakeMaker and have worked extensively on Module::Build. I think about usability problems in perl.
**Amount Requested**
$500
]]>
Comments (1)
This is a good proposal. Honestly, I think it's more important that this information be in META.yml first and in INSTALL.txt second, but maybe the other way around is a good start. By focusing on the human-readable version first, this avoids lock-in of design decisions which may turn out to be wrong. As such, I think the project should *avoid* making the data machine-readable in round one and make that a future goal.
I think the impact of this work would be minimal for experienced users, but it might make a big difference for less-invested users and for distro packagers.
