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
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
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!



Search Discussions

Discussion Posts


Follow ups

Related Discussions

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



site design / logo © 2021 Grokbase