Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 29 April 2017.
00:19 stmuk joined 01:13 stmuk_ joined 01:49 ilbot3 joined
moderator Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
03:16 eater joined
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
ugexe: that's ^^^ certainly something we should work on at the PTS
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 13:51
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:00
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:01
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:08
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:10
nine ugexe: can I leave the git URI in the META6.json? 14:19
ugexe nine: example? 14:20
nine "source-url" : "git://github.com/niner/Inline-Perl5.git"
ugexe yes, thats what is generally used
so what is the version problem you were seeing? I do not recall a recent Inline::Perl5 failure 14:23
nine Ah it was just this github.com/niner/Inline-Perl5/comm...afe1166dbd 14:24
ugexe ...how did it ever install?? 14:26
I would have guessed a precomp error would occur inside rakudo during the install from missing modules 14:27
nine It probably did.
ugexe I've installed and used Inline::Perl5 without a problem, always with zef
nine The issue has been there only since Saturday 14:30
ugexe ah 14:31
nine ugexe: this correct? github.com/perl6/ecosystem/commit/...952d1c1d46
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
nine: no, one second ill explain
you would put that cpan url in META6.json, and link that specific commit in the ecosystem (like github.com/niner/Inline-Perl5/blob...META6.json but with version 0.26) 14:34
grep the META.list for Net::IP::Lite by tbrowder - it has 2 versions in the ecosystem using this method 14:36
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
as in - thats where the ecosystem json is generated from
nine One could also just download the dists and read the META6.json from there 14:41
Like the CPAN indexer does
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
it seems to have stopped working though
github.com/ugexe/Perl6-ecosystems/.../cpan.json # this is pulled from all the .meta files in the index
nine Also what are people gonna do who don't have push access to the ecosystem repo?
ugexe use cpan or something else. and it should be fairly transparent 14:43
www.cpan.org/authors/id/P/PS/PSIXDISTS/Perl6/ 14:46
so only the old dists have a .meta file
my repo above already makes an "ecosystem" out of those (where an ecosystem is just an array of meta data) 14:47
if those .meta files were still generated then if you still wanted to list it in the ecosystem you could list that www.cpan.org/authors/id/P/PS/PSIXDI...0.001.meta 14:48
nine Odd...now zef cannot find any candidate for Inline::Perl5 anymore 14:51
ugexe not listed in ecosystem-api.p6c.org/projects.json 14:52
it probably picked up that .tar.gz and couldnt parse it as meta6.json
nine That's updated by a cron job, isn't it? 14:53
ugexe i believe so
oh hey 14:54
www.cpan.org/authors/id/N/NI/NINE/P...-0.26.meta
nine So I could use that if it's source-url would point at the .tar.gz?
ugexe yep 14:55
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
s/fine/find/
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
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.
ugexe I'm not following the git checkout part 15:02
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:05
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:06
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:07
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:09
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:16
15:17 domidumont joined
nine Cool, looks like it works now :) 15:18
samcv oh i see i hit the thing you guys are talking about 19:52
travis failed for one of my things cause couldn't get Inline::Perl5 from cpan
does it work now?
Zoffix samcv: should, yes 19:53
samcv oh well it did not
at least 20 mins ago when a travis build started. i am restartirg it tho
20:18 Zoffix joined
nine samcv: any success? 20:22
zef seems to like it
ugexe yeah that travis is using panda 20:30
samcv oh my bad i'm using panda 20:38
i thought i had changed this repo

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!