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: Perl 6 versus the CPAN
--- On Mon, 4/1/10, Eric Wilhelm enoba...@gmail.com wrote: From: Eric Wilhelm enoba...@gmail.com If Parrot itself supports trans-language calls (which I'm led to understand it can?) then a single index gives us the potentially huge win of cross-language dependencies. Does it? Tell me how the second API should work and how to build that index: look_in_index($language, $name, $author, $version); look_in_index($name, $author, $version); From the Rakudo test suite: use perl5:Text::Wrap 'wrap'; That currently doesn't work, but the intention is certainly there. I've already wanted to rewrite Term::Screen using Perl 5's Term::Cap as a dependency (because rewriting the latter is proving to be a nightmare) and when it's ready, how do I declare that my P6 code has a P5 dependency? Or, Ricardo gets to keep Config::INI and Curtis has to wait for p5 support in parrot? Fortunately, I'm not in a hurry to get this on the CPAN :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Perl 6 versus the CPAN
# from Zefram # on Monday 04 January 2010 03:23: use perl5:Text::Wrap 'wrap'; That would seem to settle it, then: perl5:Config::INI does not conflict with perl6:Config::INI. I believe that's supposed to be use Text::Wrap:fromperl5. But yes it's a different set of namespaces. --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --- http://scratchcomputing.com ---
Re: Perl 6 versus the CPAN
(I had a big response going to various details of this thread, and then realized that from Plumage's perspective, the details don't actually matter much; see the more general email below.) On Mon, 2010-01-04 at 10:45 -0500, Jesse Vincent wrote: This brings us to How do we get there from here? Who are the folks working on the Perl6 CPAN client? Well ... that's an interesting story. I'm lead developer for Plumage, the Parrot module ecosystem. Whether or not Rakudo chooses to promote it, Plumage will be available as a client, a set of modules for interacting with the ecosystem at large, and a metadata standard. (The online copy of which is out of date WRT my brain -- hopefully I can get that updated soonish.) Plumage wants to see every other module ecosystem as an API to query; systems that don't natively export an API will get wrapped by a library of ugly hacks if need be. For obvious reasons, ecosystems that *do* provide a nice API and/or metadata export facilities will get earliest and best support. :-) However, Plumage is not the only game in town, not least of which because the current implementation requires Parrot, and the larger Perl 6 community doesn't want that requirement. masak++ and mberends++ have been working on 'proto', which last I looked was Rakudo-specific but I think more as an accident of history than a planned restriction. proto however was always meant to be the one we threw away, so it may be replaced in at least the Rakudo space by Plumage. That however leaves the non-Rakudo Perl 6 implementations with no standard install client for pure Perl 6 (or otherwise cross-implementation) modules. It could be that Plumage expands to support that space, or a workalike written in pure Perl 6 takes over, or a cpan variant does. In any case, Plumage will continue to exist alongside whatever tool gets used by the broader Perl 6 community, because it's currently the only game in town for Parrot-compatible cross-language installation. Thus my main concern is that whatever the CPAN community creates, there be sane metadata standards and an easy API to work and grow with. -'f
Re: Perl 6 versus the CPAN
It's been something of a long-standing (second-order) problem that packages are just tarballs (or bzipball, or zips, etc). The lack of a standard file extension means that we can't sanely implement features like double-click to install on operating systems and browsers with file extension association capability. If we are looking at not only sharing user permissions between the two languages, but also sharing the author directories directly, this would seem like a highly opportune moment to switch to a new specific extension for P6 distributions. It would help the current indexer, because Andreas can just ignore files with that extension, and it would make it trivial for the new indexer to ignore Perl 5 and legacy files. Adam K On Mon, Jan 4, 2010 at 10:23 PM, Zefram zef...@fysh.org wrote: Ovid wrote: From the Rakudo test suite: use perl5:Text::Wrap 'wrap'; That would seem to settle it, then: perl5:Config::INI does not conflict with perl6:Config::INI. The absolutely next thing we need is naming convention for Perl 6 module distributions on CPAN: it could perhaps be p6-Config-INI-1.00.tar.gz, or Config-INI-1.00.tar.gz in a different directory from where the Perl 5 one lives. The next thing we need after that is an index of Perl 6 modules on CPAN. -zefram
Re: Perl 6 versus the CPAN
I'd rather like to avoid adding additional complexity to the current
index files.
Instead, what about switching to a native SQLite index for the new system.
This is working quite nicely in the JSAN now, and it greatly
simplifies things because you can download the index much more simply.
1. Pull gzip
2. Expand
3. Connect
If we wanted to fragment the index, we could just download the extra
parts of the index and then do an ATTACH DATABASE to load in the
additional fragment.
This would, of course, mean that SQLite and DBI support is needed in
the core for Perl 6.
But since (I gather) the P6 core will be even lighter than the Perl 5
one, and there will be a sort of Standard Library defined
independantly that includes the modules needed to install other
modules, this might not be too hard to overcome.
How hard would it be, in principle, to have SQLite and DBI support in
Perl 6? Can you do all the necessary C fu yet?
Failing this, a simple idea has been to produce a JSON structure which
has a similar logical structure to the database.
{
author_table:
...
}
Adam K
On Tue, Jan 5, 2010 at 9:15 AM, brian d foy brian.d@gmail.com wrote:
In article 20100104154532.ge6...@bestpractical.com, Jesse Vincent
je...@bestpractical.com wrote:
This brings us to How do we get there from here? Who are the folks
working on the Perl6 CPAN client?
Well, here's what I'm doing:
I think the first step is very simple. My interest is porting the Perl
6 module ideas into Perl 5. However, the code or implemention don't
matter. Once we know the answer, it's easy to go from whatever I might
do in Perl 5 to something in Perl 6.
02packages is actually quite flexible. There's a line in the header
that tells consumers what the columns are. Since we've used the same
three columns, a lot of stuff has assumed that the order and meaning
will always be the same. We fix the current stuff to pay attention to
the headers. If we reorder the columns or stick in a new column,
nothing breaks.
After that, we produce additional indices that include more
information, such as the author, a canonical flag perhaps, and other
stuff. This isn't necessarily something that PAUSE would do. Alternate
authorities can make indices. For the past year I've been working with
a couple of paying clients to make custom CPAN repositories. I have
most of the pieces in place. Think, for instance, about a market
segment
that wants to only use CPAN as it was on June 1, when their application
went into code freeze. I can produce an index that replicates that.
That's not the same thing as saving the PAUSE index since dists
disappear arbitrarily.
Once we have the index, we have a way to ask for what's available, say,
for CGI.pm. That's easy, in the sense that you don't have to draw too
much on a whiteboard, and not so bad in the pause and CPAN.pm code for
those of us who have our noses in there constantly.
Okay, all of that is step one and it's something I'm working on.
Step two is figuring out how to decide which all of the things that are
available are the most suitable. That's where a lot of people argue
endlessy in mailing lists, then Andreas or Jarkko or somebody tells us
the answer.
Re: Perl 6 versus the CPAN
# from Adam Kennedy # on Monday 04 January 2010 16:07: I'd rather like to avoid adding additional complexity to the current index files. ... This would, of course, mean that SQLite and DBI support is needed in ... the modules needed to install other modules ... ^ | download and ---' DBI is getting a bit weighty for the bootstrapping kit. I suppose you could make it a two-stage thing. Perhaps the entry point is a short index of client tools which are themselves able to fetch the bigger index(es). Failing this, a simple idea has been to produce a JSON structure which has a similar logical structure to the database. It is a generated thing, right? I somewhat like the idea of it being able to have more than one format. Piecewise updates would be grand. On a related note, I'm really liking mongodb. --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: Perl 6 versus the CPAN
On Mon, Jan 4, 2010 at 5:15 PM, brian d foy brian.d@gmail.com wrote: 02packages is actually quite flexible. There's a line in the header that tells consumers what the columns are. Since we've used the same three columns, a lot of stuff has assumed that the order and meaning will always be the same. We fix the current stuff to pay attention to the headers. If we reorder the columns or stick in a new column, nothing breaks. Yikes. How about we move away from text files and towards structured data like JSON. The (perl5) CPAN Meta Spec draft 2.0 spec is going to be JSON, not YAML, and p5p has provisionally agreed that the pure-perl JSON module can go into core when we need it to. So the moment CPAN/CPANPLUS add it as a dependency, it gets pulled into core. 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. -- David
Re: Perl 6 versus the CPAN
# from David E. Wheeler # on Sunday 03 January 2010 19:20: FYI: http://gitorious.org/parrot-plumage http://irclog.perlgeek.de/perl6/2010-01-04#i_1883152 http://perlcabal.org/syn/S11.html#Versioning http://trac.parrot.org/parrot/wiki/ModuleEcosystem --Eric -- It is impossible to make anything foolproof because fools are so ingenious. --Murphy's Second Corollary --- http://scratchcomputing.com ---
Perl 6 versus the CPAN
Hi all, I've started writing Config::INI, an INI reader/writer in Perl 6. It's on github at http://github.com/Ovid/Config-INI. This has raised several interesting issues, but the most important is that I didn't check the CPAN, but it turns out Ricardo Signes has a Perl 5 version: http://search.cpan.org/dist/Config-INI/. Can we have identically named P5 and P6 modules on the CPAN? We should be able to, but I don't that will actually fly. I know there was a fair chunk of discussion regarding Perl 6 on the CPAN, but have we gotten anywhere? More and more Perl 6 code is being written and sooner or later, people would like someplace to put it other than github or code.google.com :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
