Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-05-01

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:19 stmuk joined #perl6-toolchain
01:13 stmuk_ joined #perl6-toolchain
01:49 ilbot3 joined #perl6-toolchain
01:49 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
03:16 eater joined #perl6-toolchain
07:57 nine Looking at that Inline::Perl5 failure (missing keys in "provides"), it's a good thing that I have not declared a new version. Doesn't help at all though since our installers don't care about declared versions and just install git master :/
07:57 nine ugexe: that's ^^^ certainly something we should work on at the PTS
13:51 ugexe nine: what do you mean? zef installs whatever source-url points at - if everyone switched to using commit.tar.gz in META.list for each release it would Just Work
14:00 ugexe i've tried to avoid adding git-specific stuff because the eventual move to CPAN will require a focus on .tar.gz, so I want the abstractions I work with to make sense for both type (git / tar). So for instance: you can't download a single tar archive and extract any version you want like with a git archive
14:01 ugexe in this sense I think the solution I would lean towards is allowing commit-ids in the url that zef could understand (this even exists or existed at one time heh). but this still requires specifying each specific version as a different url in the META6.json for releases
14:08 ugexe So its not the installers dont care about declared versions (at least it shouldn't be), its that zef assumes the source-url points to the declared version
14:10 ugexe If you're getting some versioning problem from zef I have an idea where it could happen... zef first gets the module meta data from somewhere (before it downloads the repo), and if that meta data doesn't match what gets downloaded from the source-url then I suppose something might be looking at the wrong meta data
14:19 nine ugexe: can I leave the git URI in the META6.json?
14:20 ugexe nine: example?
14:20 nine "source-url"    : "git://github.com/niner/Inline-Perl5.git"
14:20 ugexe yes, thats what is generally used
14:23 ugexe so what is the version problem you were seeing? I do not recall a recent Inline::Perl5 failure
14:24 nine Ah it was just this https://github.com/niner/Inline-Perl5/commit/f1594f9fb60ba0829796d8f273b7ccafe1166dbd
14:26 ugexe ...how did it ever install??
14:27 ugexe I would have guessed a precomp error would occur inside rakudo during the install from missing modules
14:27 nine It probably did.
14:27 ugexe I've installed and used Inline::Perl5 without a problem, always with zef
14:30 nine The issue has been there only since Saturday
14:31 ugexe ah
14:31 nine ugexe: this correct? https://github.com/perl6/ecosystem/commit/bfec6ee8e3a865c1337dd9ab497f0d952d1c1d46
14:32 ugexe i used to install Inline::Perl5 as part of zef's travis tests, but OSX doesn't let you switch to the right perl :/
14:32 ugexe nine: no, one second ill explain
14:34 ugexe you would put that cpan url in META6.json, and link that specific commit in the ecosystem (like https://github.com/niner/Inline-Perl5/blob/13a06fe3e4d889769db85dfe3e6a4819055ad705/META6.json but with version 0.26)
14:36 ugexe grep the META.list for Net::IP::Lite by tbrowder - it has 2 versions in the ecosystem using this method
14:40 nine But that still very much depends on GitHub, doesn't it?
14:40 ugexe the META.list depends on github, there is no way around that
14:40 ugexe as in - thats where the ecosystem json is generated from
14:41 nine One could also just download the dists and read the META6.json from there
14:41 nine Like the CPAN indexer does
14:42 ugexe yes, although i'd like to avoid that. and this used to be easy... FROGGS added something at one time that pulled the META6.json data from the dists, so each dist had an archive and a .meta file in the index list
14:42 ugexe it seems to have stopped working though
14:42 ugexe https://github.com/ugexe/Perl6-ecosystems/blob/master/cpan.json # this is pulled from all the .meta files in the index
14:42 nine Also what are people gonna do who don't have push access to the ecosystem repo?
14:43 ugexe use cpan or something else. and it should be fairly transparent
14:46 ugexe http://www.cpan.org/authors/id/P/PS/PSIXDISTS/Perl6/
14:46 ugexe so only the old dists have a .meta file
14:47 ugexe my repo above already makes an "ecosystem" out of those (where an ecosystem is just an array of meta data)
14:48 ugexe if those .meta files were still generated then if you still wanted to list it in the ecosystem you could list that http://www.cpan.org/authors/id/P/PS/PSIXDISTS/Perl6/JSON-Class-0.000.001.meta
14:51 nine Odd...now zef cannot find any candidate for Inline::Perl5 anymore
14:52 ugexe not listed in http://ecosystem-api.p6c.org/projects.json
14:52 ugexe it probably picked up that .tar.gz and couldnt parse it as meta6.json
14:53 nine That's updated by a cron job, isn't it?
14:53 ugexe i believe so
14:54 ugexe oh hey
14:54 ugexe http://www.cpan.org/authors/id/N/NI/NINE/Perl6/Inline-Perl5-0.26.meta
14:54 nine So I could use that if it's source-url would point at the .tar.gz?
14:55 ugexe yep
14:55 ugexe so what we really need to do is fine whatever generates that .meta file and have it automatically create the proper source-url for a cpan .tar.gz
14:55 ugexe s/fine/find/
14:58 nine That'd be nice. Otherwise I'd have to update the META6.json for every release (well even more than I'd have to already).
14:58 nine Also it'd be really nice to have the git checkout's META6.json point at the git repo and the tar balls point to wherever the user actually got it from.
15:02 ugexe I'm not following the git checkout part
15:05 nine I'd like it if I could leave "source-url": "git://github.com/niner/Inline-Perl5.git" in the git repo's META6.json and have CPAN change it to the release tar ball for me.
15:06 ugexe the distinction I think that needs to be made is one of `"source-url" : "..."` vs `"support" : { "source" : "..." }`. where `support => source` should never change regardless of what content storage its on, and source-url is an *ecosystem* spec such that two distributions can be the same despite having different source-url
15:07 ugexe nine: right. so what I mean above is source-url is not meta6 spec, so cpan is free to change that to whatever it wants if it already exists (or create it if it doesnt)
15:09 ugexe what cpan cannot do is change spec fields. it cannot change "auth" : "blah:github: to "auth" : "blah:cpan" or version 1.1 to version 1.100 (or at least provide the originals)
15:16 ugexe you can also get rid of "repo-type" : "git" - there isn't any support for the field as its just inferred from the source-url
15:17 domidumont joined #perl6-toolchain
15:18 nine Cool, looks like it works now :)
19:52 samcv oh i see i hit the thing you guys are talking about
19:52 samcv travis failed for one of my things cause couldn't get Inline::Perl5 from cpan
19:52 samcv does it work now?
19:53 Zoffix samcv: should, yes
19:53 samcv oh well it did not
19:53 samcv at least 20 mins ago when a travis build started. i am restartirg it tho
20:18 Zoffix joined #perl6-toolchain
20:22 nine samcv: any success?
20:22 nine zef seems to like it
20:30 ugexe yeah that travis is using panda
20:38 samcv oh my bad i'm using panda
20:38 samcv i thought i had changed this repo

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary