Re: Perl 6 versus the CPAN
Hi David, hi all, David Golden wrote: Except that we're in feature freeze for Perl 5.12, so that won't actually happen until 5.13. But as soon as Perl 5.12.0 ships, I plan to pull the trigger on JSON and HTTP::Lite and make them CPAN.pm dependencies so we can (a) bootstrap CPAN with HTTP and (b) start consuming JSON metadata (and index) files. Amen to that! Regarding SQLite via DBI indexes: Nice idea *after* bootstrapping. But in practical terms, that's never going to fly. p5p will reject any proposals to include anything like SQLite or DBI in core. That doesn't stand the chance of an ice berg in hell. Don't waste your time musing about it. Going one step away from core-ifying that: Bootstrapping this would make initial CPAN client setup a VERY painful experience and I am still under the impression that we[1] are currently trying to make this a smoother experience. I believe structured ascii (or Unicode) text data with a light-weight parser in core is our best bet. The only thing that worries me about this is memory consumption for large index files. Best regards, Steffen [1] This is a literary we in the sense of: Golden et al. Particularly NOT including myself.
Re: Perl 6 versus the CPAN
In article 5d4beb41001041958q3b5d9219gac4360cfc8c2d...@mail.gmail.com, David Golden xda...@gmail.com wrote: On Mon, Jan 4, 2010 at 5:15 PM, brian d foy brian.d@gmail.com wrote: Yikes. How about we move away from text files and towards structured data like JSON. When JSON is core that would be great. I'd love the data to be in all sorts of formats, but the fresh Perl install needs to work too.
Re: CPAN vs Perl 6
# from brian d foy # on Tuesday 05 January 2010 02:27: Yikes. How about we move away from text files and towards structured data like JSON. When JSON is core that would be great. I'd love the data to be in all sorts of formats, but the fresh Perl install needs to work too. Yeah but JSON has pink unicorns so there. There's nothing wrong with tsv files. One or more formats of reports or extractions from the data should be able to be generated. Currently, you get the one format and generate your preferred thing locally. That's fine but you can't get updates -- for that you need a rowid or something. --Eric -- It is a mistake to allow any mechanical object to realize that you are in a hurry. --Ralph's Observation --- http://scratchcomputing.com ---
Re: CPAN vs Perl 6
# from David Golden # on Tuesday 05 January 2010 15:00: There's nothing wrong with tsv files. There's nothing wrong with punched cards and slide rules, either. ...except for complexity, lack of speed, accuracy, etc. If you want to emit a table of information which is known to have no embedded tabs, a tsv file with headers is fast and easy to produce and consume without special software on either end. Given the constraint of bootstrap-ability, it seems like you should answer Why not tsv? before reaching for anything more complicated. --Eric -- To a database person, every nail looks like a thumb. --Jamie Zawinski --- http://scratchcomputing.com ---
Re: CPAN vs Perl 6
On Tuesday-201001-05 19:48, David Golden wrote: On Tue, Jan 5, 2010 at 6:19 PM, Eric Wilhelm enoba...@gmail.com wrote: Given the constraint of bootstrap-ability, it seems like you should answer Why not tsv? before reaching for anything more complicated. Because META is already multi-dimensional and I don't want to find or re-invent a wheel for representing multi-dimensional data in tsv. The YAML/JSON debate is pretty much over as far as the META spec goes and JSON wins. Thus, given the pending arrival of JSON into core for META, I see no So you are saying screw the older Perl distributions? reason not to use JSON for index information as well. The last thing we need is for CPAN/CPANPLUS/Tool-X to all implement their own tsv parsers and we don't already have one in core, do we? (I could be Yes, it's called and split(/\t/). wrong there). This is such a stupid bikeshed conversation anyway. Wait until you see the color we chose. David
Re: CPAN vs Perl 6
As much as I like JSON I agree that for CPAN.pm like programs a variation of the current index really seems like the best match (5 lines of perl for the parser; backwards compatible; easy-ish to make as memory efficient as possible). For other tools having a more complete data structure would be nice; but there's no reason that PAUSE couldn't produce indexes in different formats. If so then the optional fancy index could be any combination of SQLite, JSON, buzzword-bingo-of-the-day that we like. - ask
Re: CPAN vs Perl 6
... or, like JSAN does, all of the above. We make multiple different formats available, as many as people ask for pretty much. As long as they stay in sync, there's no real problems that happen from encoding the index in N number of ways. Adam K On Wed, Jan 6, 2010 at 2:59 PM, Ask Bjørn Hansen a...@perl.org wrote: For other tools having a more complete data structure would be nice; but there's no reason that PAUSE couldn't produce indexes in different formats. If so then the optional fancy index could be any combination of SQLite, JSON, buzzword-bingo-of-the-day that we like.
