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 8 May 2018.
01:58 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
11:49 domidumont joined 11:57 domidumont joined 16:24 ingy joined
ingy I'd like to change github.com/perl6/ecosystem/blob/ma....list#L105 16:35
How would I go about doing that?
AlexDaniel` by change you mean add your module? 16:36
ah, I see, you linked to some line
ingy raw.githubusercontent.com/perl6-co...META6.json
AlexDaniel` ingy: just change it? 16:37
you should have access
ingy ok
is that the SSoT for where installers will find the module? 16:38
ie do I need to change anything else?
AlexDaniel` it's not single because now there's also CPAN
but no, just changing that should be enough
ingy I'm not planning on using cpan/pause 16:39
cool
one more question
AlexDaniel` that's ok :)
ingy I want to use a non-master branch if possible
AlexDaniel` no problem with that, it should work
ingy ok
actually I want to do that later on, but good to know 16:40
AlexDaniel` to be honest I'm not entirely sure how it works exactly 16:41
so you can point to a non-master META6.json, that works
so this, for example, works: raw.githubusercontent.com/niner/In...META6.json
but then the source-url has to be something else… 16:42
I do remember people who did that though
github.com/perl6/ecosystem/blob/ma...#L733-L735 16:43
here for example
ingy seems like it would require a source-commit or something
I don't see how that allows someone to install more than one version of Ddt 16:46
AlexDaniel` yes… 16:47
well, it's going to ā€œthinkā€ that it's installing a different version
but I guess it'd pull exactly the same sources 16:48
ingy well today I only need master
but seems like something to figure out
AlexDaniel` ingy: I found it! 16:52
github.com/rakudo/rakudo/archive/js.zip
github.com/rakudo/rakudo/archive/master.zip
that's what you should use for the source-url
well, I mean, at least this way it'll do what you want :)
ingy so github creates the archive from .../<commit>.zip on the fly? 16:54
AlexDaniel` seems so 16:55
ingy curl -L -o rakudo.zip github.com/rakudo/rakudo/archive/e0ad668.zip 16:58
works!
try it, then: unzip -l rakudo.zip 16:59
AlexDaniel` zef should also understand it
ingy you get lines like 6500 05-09-2018 08:06 rakudo-e0ad668e228dba13147b28aacb0fe965d3d1db2f/tools/create-release-announcement.p6
AlexDaniel` I found it in tbrowder++'s modules raw.githubusercontent.com/tbrowder...META6.json
ingy sweet 17:00
AlexDaniel`: what does this mean: "version" : "*", 17:11
in META
AlexDaniel` ingy: it's the version of your module 17:13
ingy I mean *
AlexDaniel` * is unspecified, I think
ingy is there a META definition doc? 17:14
AlexDaniel` I don't expect to see that in an actual module :)
ingy it's actually in mine
AlexDaniel` there is some documentation here: docs.perl6.org/language/modules#in...META6.json 17:15
ingy github.com/ingydotnet/testml-pm6/b...META6.json
AlexDaniel` but I think some extra info can be found in speculations
design.perl6.org/S22.html#version
↑ this is likely outdated 17:16
ingy yeah
I'll piece it together :) 17:17
AlexDaniel` here's some extra info on versioning: design.perl6.org/S11.html#Versioning
ingy I don't think I added "*" 17:18
AlexDaniel` very likely it was there in previous versions of the docs
ingy 82ba6354 META.info (Nick Patch 2011-06-15 16:35:15 -0400 4) "version" : "*",
AlexDaniel` hmmm
ingy anyway, I'm going to change it to a real version 17:19
AlexDaniel` ingy: anyway, I'm heading home now. BTW you're more likely to get help on #perl6 or #perl6-dev šŸ™‚
ingy I assume there's no problem going from 0.01 to 0.0.2
like in perl5
AlexDaniel`: thanks for your time!
nine Actually S22 is pretty up to date 17:27
AlexDaniel` oh
nine: maybe we should move it to docs then?
nine I updated it at last year's PTS. This year we got got the toolchain to actually support much of what we designed last year 17:28
ingy: perl6 -e 'say Version.new("0.01") cmp Version.new("0.0.2")' 17:29
More
ingy nine: is that going to break anything though 17:34
does any part of the toolchain check to see if versions only increase?
nine We usually load the highest installed version matching the dependency specification 17:35
ingy by We you mean rakudo? 17:36
perl6 -e 'say Version.new("0.01") cmp Version.new("0.2.0")' # Less 17:37
which is better than what p5 thinks! 17:38
I'll just use 0.2.0
mst I *believe* that perl6's versions are always dot-separated multipart 19:18
rather than the "maybe decimal, maybe dot-separated" hilarity we have from retrofitting dot-deparated into perl5 19:19
nine Well.... a Perl 6 Version is a list of numbers and strings of alphabetic characters optionally separated by anything else. So e.g. 1;1ab,2 and 1.1.ab.2 are treated as equal 19:50
Alphabetic characters or underscore that is 19:51
mst so dot-seperated multipart with bells and whistles ;) 19:52
(this is not a bad thing :)
nine It can create a bit of a weird thing from a git version like 2018.04.1-40-g56c03572a which is turned into v2018.04.1.40.g.56.c.03472.a but in practice it works just fine 19:54
I guess versions are the only thing where the difference between perceived simplicity and clarity on the one hand and actual madness in real life on the other exceeds CSV's 19:56
20:16 El_Che joined
El_Che hi, a link a posted on #perl6 about changing to dependency versioning in upcoming go releases. I think some of it could match to perl6. It's an interesting take on how they started trying to copy cargo but ended elsewhere 20:17
www.youtube.com/watch?v=F8nrpe0XWRg
mst having read the various articles about the new system 20:32
trout.me.uk/mstcat2.jpg
El_Che it made sense to me 20:34
go got away with the fragile dep system because you could vendor it in in your repo and the result was statically compiled 20:37
perl6 doesn't have that 20:38
only the fragility
anyway, it's just a pointer (the interesting part is how the dropped dep for vgo) to see what other people do 20:39
mst it's rather restricted compared to perl6 20:46
cargo is IMO a more interesting model
basically: vgo is intentionally incredibly restricted in what it can do, just like the rest of go 20:47
this is the exact opposite of perl's response of "sure, how much rope would you like?"
though 20:52
a perl6 client w/custom CUR resolver that implements the vgo style approach
would be interesting
El_Che mst: yes, I agree 20:58
but it breaks less as a plus
perl6 has more possibilities
mst when I looked at it I saw a bunch of subtle ways it'll break later 20:59
I don't have a list memorised though
I think there's a few blog posts that provide one
El_Che I like having the info on the code file instead of in metadata though
for go
perl6 support the auth + version adverbs for namespacing while they just url's for that 21:00
mst "info on the code file" ?
El_Che import "github.com/educated/fool" 21:01
import "github.com/educated/fool/v2"
import "github.com/educated/fool/v3"
same url == api is backwards compatible
there is no versioning 21:02
they are all different packages
(for go)
mst right 21:03
El_Che if stuff breaks in sutle ways, as you put it, it's the responsability of the community to fix it 21:04
almost verbatim quote
mst yes
classic 80% solution thinking
which is go all the way down
El_Che well, they come from no versioning at all
mst (and that's not a criticism)
El_Che so I'll take the 80 :) 21:05
mst the entire language is based on the "80% solution" trade-off
El_Che yes
go made it a virtue
of course there is no infrastructure 21:06
so versioning is dependent on the people provinding modules 21:07
so it could strand there
I would have prefered to have a system based on git tags
(they are pretty github centric)
(or git centric at least) 21:08
what I would like to have is the casual forking of libs 21:09
mst perl6's AUTHORITY system is such a cool idea there
El_Che more than once there was a lib a used, send a PR that tooks ages to be merged, in the meantime imported my fork in my code
make it very easy to try stuff out 21:10
mst right, I wrote p3rl.org/App::opan to solve that for me
El_Che I know opan 21:11
it's not what I would call casual
mst huh?
opan add ./TheThingIForked-0.001.tar.gz
opan pull
opan carton install 21:12
El_Che you build infrastructure while the idea is that there is none
mst pretty casual to me :)
I don't regard 'a command line tool' as 'infrastructure'
El_Che it's not heavy
or complicates 21:13
but a server is infrastructure
mst there's no server
El_Che there was an opan daemon when I tried it
mst you *can* run an opan server, and some people do
El_Che it was a while ago though
ah, ok
mst what I just showed you above was the entire commands
GAAAAAH
people's top two complaints about opan: 21:14
1) I want to be able to run a server, why is it CLI only?
2) I don't want to run a server, why isn't it CLI only?
El_Che I can guess 2
:)
mst bashes face against desk
'opan carton install' fires up a temporary server on a free localhost port, points carton at it, and murders the server when it's done 21:15
so, ok, *technically* there's a server, but that doesn't really count
El_Che open is a great answer for the cpan worl
d
mst any more than 'installing a module that uses Test::TCP' counts as 'running a server' ;)
El_Che but not for a github centric setup
mst sure
though honestly I've done it for github centric stuff 21:16
El_Che quo vadis, perl 6
is the questio
n
mst took git hub listrepos <orgname>, checked out all their repos, ran 'make dist', injected into opan, installed customer product
El_Che when you have open, everything looks like cpan :) 21:17
mst LOL
I wrote it in a weekend to deal with a client's github org's repos ;) 21:18
I have some ideas for things that could be done for perl6 but, uh, they're sort of dependent on some yak shaving I've been doing for enough years that I'm starting to look like I'll take as long as perl6 did to release ;) 21:19
El_Che when in rome... 21:26