On Jan 7, 2010, at 8:38 PM, David Golden wrote: > Thoughts in no particular order:
Thanks for these, David. > * 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. Good point. I'll probably require Archive::* to start with in the PGAN client. But implementation aside, I can add a note about .zip. > * META spec -- don't get too wedded to the CPAN spec until we finish > 2.0 and you decide if you still like it. So far so good. I don't expect to get to the client until after 2.0 is finished anyway. > * I don't see how a Makefile can be optional if you need it to build > extensions Hrm. Well you can upload scripts to CPAN. Did you know that? CPAN.pm doesn't know what to do with them, but they're there. I was just trying to keep things as open as possible. Might end up requiring it anyway, for the reasons you cite. > * 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 > minutes!) Will have to check that out. I plan to steal everything I can can from PAUSE, CPAN, CPAN.pm, CPANPLUS, and JSAN::Client. > * 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 > DWIM Yeah, should be easy. > * 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. I'm not doing that part. I'm relying completely on PGXS, which is the Makefile included in PostgreSQL builds (postgresql-devel packages), to supply all that stuff. I don't want to go near the actual build system. Way too many bikeshed colors there and not my area of expertise in the slightest. > * 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 Good call. > [Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS > config system may be my QA hackathon project.] I'll be at OSCON for sure! Best, David
