Camelia, the Perl 6 bug

IRC log for #cpan6sketch, 2010-09-21

| Channels | #cpan6sketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
12:56 tadzik joined #cpan6sketch
13:01 masak joined #cpan6sketch
13:42 tadzik left #cpan6sketch
13:43 tadzik joined #cpan6sketch
14:06 tadzik meeting in 2000?
14:06 tadzik * 2 hs
14:06 * moritz_ is lost on the math
14:08 masak tadzik: yes, about two hours left.
14:09 * masak realizes belatedly that it'll be tricky to make+eat dinner after #cpan6sketch and before #phasers...
14:25 masak oh well. I'm here for #cpan6sketch, and I'll try to make it in time for #phasers :)
14:50 pmichaud joined #cpan6sketch
15:36 JimmyZ_ joined #cpan6sketch
15:37 JimmyZ_ \o
15:37 JimmyZ_ 23 minutes remaining?
15:37 moritz_ I might miss the start of the meeting :/
15:46 TimToady joined #cpan6sketch
15:55 mberends joined #cpan6sketch
15:58 JimmyZ_ left #cpan6sketch
15:59 takadonet joined #cpan6sketch
16:00 masak o/
16:00 mberends \o
16:00 gottreu joined #cpan6sketch
16:01 masak I heard there was a meeting in these parts.
16:02 tadzik \o/
16:02 jnthn joined #cpan6sketch
16:03 pmichaud 1600utc
16:03 pmichaud (1603, actually)
16:03 pmichaud was this the new designated time for a meetup?
16:04 masak aye.
16:04 pmichaud I never heard, officially.
16:04 masak ok, I'll get the ball rolling. right now we don't have much of a module system. what we have is pretty bare-bones. it'd be great to connect the current ecosystem to CPAN somehow.
16:05 mberends I must admit to not knowing much about how CPAN works internally
16:05 pmichaud Me either
16:05 JimmyZ_ joined #cpan6sketch
16:06 masak this meeting needs someone who does.
16:06 mberends something that I think we should change in our current tools is the dependency on Git and/or Subversion.
16:07 tadzik so, we need a place to put the tarballs.
16:07 tadzik Which drives us straight to CPAN
16:07 pmichaud ooc, why would we want to eliminate the dependency on git?
16:08 rgrau` joined #cpan6sketch
16:08 tadzik I'm ok for git, then we could just checkout the tags
16:09 pmichaud with git, we get a lot of "free" metadata that is lost if we move to tarballs
16:09 pmichaud and there were several other advantages that schwern++ noted when he moved CPAN to github
16:09 mberends because the end users are not necessarily developers, so it's an extra installation requirement
16:09 pmichaud ("built a github repo of CPAN", more precisely)
16:10 mberends git uses port 22, which is not as widely usable as port 80
16:10 pmichaud so, you're wanting to eliminate the dependency on git checkouts, not necessarily on git as a storage/management mechanism
16:10 tadzik git can use 80, or the git protocol
16:10 pmichaud almost anything we use is going to require an "extra installation requirement".  Even cpan requires an extra tool :)
16:10 masak to me, saying "we need to get rid of git" gives far to much credit/weight to the solution we already have. everything I've seen so far won't survive the next three years.
16:10 tadzik in fact, it doesn't really use 22 if you are just cloning/pulling
16:11 masak s/to/too/
16:11 mberends right now behind a firewall:
16:11 mberends git pull ssh: connect to host github.com port 22: No route to host fatal: The remote end hung up unexpectedly
16:12 tadzik then why to pull via ssh?
16:12 tadzik if you do, you surely are a developer
16:12 masak the regular CPAN client has/had problems with firewalls as well, IIUC.
16:12 tadzik you can easily clone via http, that's even default (default link) on github
16:12 masak cpanminus seems to fare better, since you can just curl-bootstrap it.
16:13 masak cpanminus++
16:13 mberends aye, how hard is it to emulate cpanminus?
16:13 tadzik emulate?
16:13 masak we need rakudo to accept a script via STDIN :)
16:14 pmichaud ...whether we grab things on port 80 versus port 22 isn't the key point.  Either way we have to write/have some "extra tool" on the local end that knows how to talk to the remote server
16:14 tadzik we need FatPacker
16:14 tadzik excuse me, are we planning to put our modules on good ol' cpan, or create something completely new?
16:14 pmichaud tadzik: that's not decided yet (more)
16:15 pmichaud imo, we want to build something that can eventually go beyond cpan
16:15 tadzik beyond?
16:15 pmurias joined #cpan6sketch
16:15 pmichaud cpan has its own limitations; we don't necessarily want to bind ourselves to them permanently
16:16 gottreu And avoiding headaches and confusion for Perl5 users with some separation between 5 and 6, no?
16:16 tadzik such as?
16:16 pmichaud tadzik: metadata management is one
16:16 mberends as with bootstrapping Parrot, it would be nice to assume that the user has a simple Perl 5 installation, and try to avoid adding many other dependencies. Perl 5 can do LWP downloads and unpack zipped tarballs.
16:16 tadzik some of the metadata can be kept in the module declaration syntax
16:17 pmichaud tadzik: but you also have to be able to index and query it efficiently
16:18 tadzik so 2 things: data in the modules themselves, and the place keeping them
16:18 pmichaud mberends: I'm thinking that we should be able to come up with a pure p6 solution
16:19 pmichaud rather than saying "we're going this way because perl 5 has ...."
16:19 pmichaud creating a simple LWP for rakudo shouldn't be that hard
16:19 tadzik well, there is one
16:20 mberends pmichaud: ok, also tarball unpacking (binary data handling)
16:20 pmichaud mberends: only if you assume tarballs
16:20 tadzik using git is against pure-perl6 too
16:20 JimmyZ_ left #cpan6sketch
16:20 [Coke] joined #cpan6sketch
16:21 mberends pmichaud: true, metadata is best formatted as UTF-8
16:22 pmichaud tadzik: you don't think we could have a simple git client written in perl 6?
16:23 tadzik pmichaud: well, we could
16:23 TimToady pure-perl6 will make it hard to use carrier pigeons too
16:25 tadzik so, are we planning to use git? I think it'll be good to settle on something
16:25 tadzik what kind of metadata does git exactly give us>?
16:26 tadzik emails, alright
16:26 pmichaud at this point I'm less interesting in saying "what are we going to use" than hearing the things we should avoid (and why)
16:26 pmichaud a lot of cpan-proponents have said "don't repeat p5's mistakes" and "learn from cpan".  I'd like to know what those are.
16:28 pmichaud since we don't really have any cpan experts here, I propose that we (I) do the following
16:29 pmichaud I'm going to contact obra++ and schwern++ and perhaps a few others directly and say "what do you think we should do for module management in rakudo/perl 6, and why?"
16:30 mberends +1
16:30 pmurias +1
16:30 masak +1
16:30 pmichaud I'll then summarize our conversation.  If the conversation takes place via irc, it'll be logged somewhere.
16:31 pmichaud I don't necessarily want a lot of people involved in the conversation to begin with, because (as this session demonstrates to me), it's too easy for there to be unstated assumptions about what can and cannot be done that can color the discussion
16:32 moritz_ +(1..Inf).pick
16:32 * TimToady hangs
16:32 mberends I'd like to see some evolving documentation about the issues first. Since these meetings don't seem to get the crucial attendees, shall we collaborate in a repo of docs instead?
16:32 pmichaud I can do a repo of docs, yes.
16:33 pmichaud I was thinking that it would eventually evolve to a mailing list
16:33 pmichaud but to avoid the bikeshed trap, a repo of docs might be better.
16:35 pmichaud anyway, chatting with those folks or initiating conversations will be my task for the week.  I can either report back here at 1600 utc or (my preference) repoart back at #phasers next week
16:35 mberends #phasers is fine
16:39 rgrau` left #cpan6sketch
16:40 pmichaud okay, that's my plan.  Anyone have any other plans or modifications they wish to add?  ;-)
16:40 masak good luck!
16:41 masak (and I mean that; I'm not being ironic or anything)
16:41 mberends :)
16:46 gottreu Are there any thoughts regarding integration or cooperation with package systems of the OS?
16:46 masak it's come up at at least one YAPC.
16:46 masak YAPC::EU 2009, I believe.
16:46 masak I don't remember who it was that wanted to work with that, though.
16:47 masak maybe mberends does.
16:47 * moritz_ just know it's a tough question, and best deferred until later
16:47 mberends it's definitely a requirement, and where people with .deb .rpm and .msi skills are needed
16:48 pmichaud I think that's the role of distributions to handle.
16:50 gottreu The new ModuleHaus could provide helpful metadata to the distributions.  (e.g. security fix vs feature addition)
16:51 gottreu s/to/for/
16:53 masak left #cpan6sketch
17:01 mberends nom &
17:01 mberends left #cpan6sketch
17:06 gottreu In the same vein, if  PyPI, rubygems, CRAN, CPAN, and other groups all worked together with distributions to normalize OS packing <-> language packaging, that'd be full of rainbows and bunnies.
17:16 PerlJam Hey!  There's activity here for a change!  :)
18:20 pmurias left #cpan6sketch
19:47 takadonet left #cpan6sketch
20:38 tadzik left #cpan6sketch

| Channels | #cpan6sketch index | Today | | Search | Google Search | Plain-Text | summary