On Thu, Jan 7, 2010 at 5:36 PM, David E. Wheeler wrote:
My hope is that it's full of JFDI! I would be very grateful for feedback and suggestions.
Thoughts in no particular order:
* Limiting to gzip/bzip2 tarballs may screw over Windows users who
don't have access to a portable extraction program. (CPAN also
supports .zip files.) Perl papers over these cracks with Perl
(Archive::*), but PGAN won't have that as an option.
* META spec -- don't get too wedded to the CPAN spec until we finish
2.0 and you decide if you still like it.
* I don't see how a Makefile can be optional if you need it to build extensions
* Don't be specific about update frequency for a search site.
"Updated as often as is practical" or something vague like that. (If
you implement Andreas fast mirroring system, you can update within
* PGAN client -- decide if you want to have command arguments like
apt-get (e.g. "pgan install Foo") or whether you want to be like cpan
without them (e.g. "cpan Foo"); most OS installers seem to use
'install' so either choose that or make your client smart enough to
* Define a "minimum API" between pgan and make, including arguments
that all Makefiles must support. You want to avoid the soup of
arguments that EU::MM and M::B have built up. Do you need "make
installdeps"? Do you need an equivalent to INSTALL_BASE? Standardize
* Create a common configuration file with sections for different
things like mirrors, commands, etc. Have a 'pgan' section for things
that are specific to that particular client only. That way, when
someone writes pganplus, it can us the same common configurations
[Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS
config system may be my QA hackathon project.]