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
these now.

* 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.]

-- David

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 11 | next ›
Discussion Overview
groupcpan-workers @
postedJan 7, '10 at 10:36p
activeJan 8, '10 at 6:04p



site design / logo © 2021 Grokbase