Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2016-09-06

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

All times shown according to UTC.

Time Nick Message
04:19 Lee_ joined #metacpan
06:49 oiami joined #metacpan
06:50 batman joined #metacpan
06:59 batman joined #metacpan
07:11 osfabibisi joined #metacpan
07:48 BooK more issues with MetaCPAN: https://metacpan.org/release/CHCAT/HBase-JSONRest-0.045 (still marked unauthorized), so https://metacpan.org/release/BDEVETAK/HBase-JSONRest-0.044 should be shown when looking for it
07:48 BooK but https://metacpan.org/search?q=HBase::JSONRest&search_type=modules returns nothing
07:48 BooK and https://metacpan.org/author/BDEVETAK lists no releases
07:48 BooK https://metacpan.org/author/BDEVETAK/releases has them, though
07:49 BooK Yesterday, mickey said a reindexing was needed. If one happened, then the issue remains.
07:54 edward joined #metacpan
07:57 mickey BooK: switch to v1 :)
08:00 BooK mickey: how do I do that, and more importantly, how does the rest of the world do that? :-)
08:00 mickey ah, you should have been to YAPC :D
08:00 mickey https://v1.metacpan.org/
08:01 BooK mickey: yes I should
08:01 mickey :)
08:01 BooK hopefully, I'll finally attend another YAPC Europe next year
08:02 mickey if you're using the API directly, use https://fastapi.metacpan.org/
08:05 Relequestual joined #metacpan
08:11 BooK mickey: if I had been at YAPC, I guess I would also have heard the planned date for the switch to v1? ;-)
08:11 mickey yes, EOY
08:14 neilb joined #metacpan
10:27 karjala the favorites listed here and here are not the same: https://metacpan.org/author/KARJALA and https://v1.metacpan.org/author/KARJALA
10:27 karjala is that a bug on MetaCPAN's side?
10:27 karjala Which of the two lists is correct?
10:37 ranguard karjala: v1 does share fav data with the main site
10:37 ranguard v1's data will be replaced with the data from https://metacpan.org/author/KARJALA when we go live
10:38 ranguard oalders: ^^ maybe we need to mention that on v1?
10:38 ilmari ranguard: does or doesn't?
10:38 karjala does or doesn't?
10:42 karjala So if I add a favorite on v1, will that not get replicated in v0?
10:42 karjala ranguard: ^^
10:47 mickey i wouldn't expect anything to be replicated from v1 to v0
10:48 mickey favs in v1 are just sandbox for testing atm
10:53 mmp joined #metacpan
11:08 ranguard karjala: what mickey said - sorry for the confustion
12:56 anon joined #metacpan
13:45 Khisanth joined #metacpan
14:31 oalders we do need to be clear about v1 not being a safe place for your data
15:53 mtj joined #metacpan
17:13 metacpan joined #metacpan
17:13 metacpan [metacpan-web] ranguard pushed 1 new commit to leo/fastly_add_keys_for_caching: https://git.io/viZoo
17:13 metacpan metacpan-web/leo/fastly_add_keys_for_caching c1c37d2 Leo Lapworth: whole load of tidying going on
17:13 metacpan left #metacpan
17:58 metacpan joined #metacpan
17:58 metacpan [metacpan-web] mickeyn created mickey/fix_warning_uninitialized (+1 new commit): https://git.io/viZD2
17:58 metacpan metacpan-web/mickey/fix_warning_uninitialized ab22228 Mickey Nasriachi: fix warning: check uninitialized value
17:58 metacpan left #metacpan
18:03 ranguard should we set HTTP client cache headers for ANY of the responses from the API?
18:07 ranguard mickey: ^^ ?
18:07 ranguard oalders: ^^ ?
18:15 neilb joined #metacpan
18:26 oiami1 joined #metacpan
18:39 metacpan joined #metacpan
18:39 metacpan [metacpan-web] ranguard pushed 1 new commit to master: https://git.io/viZdX
18:39 metacpan metacpan-web/master b97dafc Leo Lapworth: Merge pull request #1770 from metacpan/mickey/fix_warning_uninitialized...
18:39 metacpan left #metacpan
18:39 metacpan joined #metacpan
18:39 metacpan [metacpan-web] ranguard deleted mickey/fix_warning_uninitialized at ab22228: https://git.io/viZd1
18:39 metacpan left #metacpan
18:56 oalders ranguard: i can't think of any API responses which we'd need to cache
19:01 ranguard oalders: ok, just CDN caching then
19:01 ranguard if I have a 'require' in a Moose Role, can't another role forfil it?
19:02 mst no, because 'require' is to run time load a perl module
19:02 ranguard well that sucks
19:02 mst did you mean requires() by any chance?
19:02 oalders i think that's what he meant
19:02 ranguard oh, yea that that!
19:02 mst yeah, I'm just passing time until he tells me what he's actually done so I can help debug it
19:03 ranguard I did https://v1.metacpan.org/source/LLAP/MooseX-Fastly-Role-0.01/lib/MooseX/Fastly/Role.pm#L8
19:03 ranguard thinking: https://github.com/metacpan/metacpan-api/blob/master/lib/MetaCPAN/Role/HasConfig.pm
19:04 ranguard and with 'Metacpan::Role::HasConfig', 'MooseX::Fastly::Role';
19:04 ranguard woudl be ok
19:04 mst it won't, because attributes in Moose roles don't yet have methods, so the merging doesn't handle it
19:05 mst with 'MetaCPAN::Role::HasConfig'; with 'MooseX::Fastly::Role'; might work
19:05 mst or you could switch to Moo, where this would IIRC work in the first place :P
19:05 * ranguard tried the 2 'with' optoions
19:05 mst hmf
19:06 ranguard Oh! - might find found something
19:07 ranguard Oh! - might find found something, yep, odd roles using roles, but found the right 'with' order to make it work
19:08 ranguard thanks
19:19 ranguard bother, thought I was 99% there, but this just isn't right, will come back to it another day
19:59 oiami joined #metacpan
21:01 neilb joined #metacpan
21:59 gordonfish joined #metacpan

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