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 1 May 2016.
05:53 domidumont joined 05:58 domidumont joined 06:06 domidumont joined 06:36 domidumont joined
MadcapJake Ok didn't get as far as I'd hoped. Here's my (not yet working) progress: github.com/MadcapJake/rakudo/commi...bcde94c535 06:49
08:00 domidumont joined 08:31 jdv79 joined 08:36 domidumont joined 10:37 JimmyZ joined 11:09 domidumont joined 12:06 domidumont joined 13:09 sufrostico joined 13:36 sufrostico joined 14:01 domidumont1 joined 15:15 [Coke]_ joined 15:19 Brock joined 15:20 hoelzro_ joined, sufrosti1o joined 15:24 JimmyZ joined
MadcapJake nine_: I'm not sure I understand what you mean by the second option "before removing the file, check if any other module would provide the same short-id" 16:11
nine_ MadcapJake: right now, you just remove the file, even if there would be other modules (or versions of your module) that provide an implementation. 16:12
MadcapJake: my suggestion is to check if there are other modules that do that and if there are just not delete the file yet 16:13
MadcapJake ahh yeah I see, I like that option but I'd need to check the short/ for another module with that short-name, right? 16:16
nine_ Considering the packaging issues, I'd actually prefer option 1 16:18
MadcapJake alriiiight ;) 16:22
[Coke]_ finanalyst.github.io/ModuleCitation/ 16:27
(list of modules that refer to other modules)
MadcapJake that's epic! 16:30
interesting how you can see JSON::Fast being used in favor of JSON::Tiny 16:59
17:08 tadzik joined 17:36 domidumont joined
[Coke] tadzik: I have one outstanding PR for rakudobrew, and two open issues - the biggest issue is that you added a second 'moar-bleed' backend, but there's no way to distinguish it from 'moar' for the user, so it's kind of confusing. 17:45
Not sure if the right answer on that is to expose it as moar-blead more directly, or remove it.
17:50 Kassandry joined
[Coke] looks like it was added 2 weeks ago: github.com/tadzik/rakudobrew/commit/309424c0 17:53
tadzik ouch 17:58
I added it at tux's request
yeah, name should be changed
that should do it 17:59
[Coke] thanks, closed the ticket. 18:00
I opened about 3 more, though. :) 18:02
I did do github.com/tadzik/rakudobrew/pull/90 if you want, though. 18:03
tadzik Merg'd, thanks :) 18:05
[Coke] #93 is because git protocol of git resolves to: 18:06
git ls-remote --tags git://github.com/rakudo/rakudo.git
but that should be:
git ls-remote --tags git@github.com/rakudo/rakudo.git
er:
git ls-remote --tags git@github.com:rakudo/rakudo.git
the latter is smart enough to use my ssh over https bridge. the first is trying to lookup github.com directly in DNS which isn't going to work here. 18:07
I can fix that so if protocol is git, it uses @..: instead of ://.../ if you like. (and leaves it as is for anything non-git) 18:08
(commented on #93) 18:09
tadzik ah
does git@github.com allow it to work with people who don't have a github account and ssh key though? 18:10
maybe https:// would be safer
[Coke] if they want https, they can ask for it already. 18:11
with the undocumented GIT_PROTOCOL 18:12
(which needs documenting, one sec, ticket coming. :)
18:21 cognominal joined
[Coke] tadzik: pretty sure it works if your project is public. 18:27
(we have issues with private repos using github enterprise, but I would be surprised if they happened on public repos @github.com) - it's easy to test though, you can move your key out of the way. 18:28
MadcapJake nine_: I've set up the repository short-id subdir idea, but I can't decide which one will be chosen, traverse and pick the latest ver/api? 18:36
nine_ MadcapJake: that's....a good question. I thought we could let .need decide that but in this case there could even be different short-names 18:42
MadcapJake right, need needs a decision on the DepSpec and for that we'll need to make a decision on which file within that given short-id's dir we should use 18:43
(currently I'm just doing the same as short/, each file's name is the dist.id and the contents is a line-separated ver/auth/api) 18:44
nine_ Much complexity just to have short ids instead of full class names :/ 18:45
perlpilot
.oO( torturing developers on behalf of users ... )
 18:47
MadcapJake I'm more worried about a performance hit than complexity 18:49
nine_: I think we have to remember that repositories won't be in the magnitude of modules so perhaps traversing (or even moving back to a single file model) would be better performance-wise? 18:50
If we returned to a single file model, on installation we could sort by version/api which would reduce the need for parsing to just the first line (then we'd need to allow users to specify an older version/api somehow) 18:53
nine_ That still dosn't answer the question: if both Foo and Bar implement a "baz" repository, which one do you load? 18:56
MadcapJake oh yeah :\\ 18:57
nine_: a new pragma e.g., `use repo :gx(CompUnit::Repository::GX);` 19:00
nine_ Or we just refuse to install Bar 19:03
MadcapJake that was my other thought but seems kind of limited. What if johnny wrote a repo for github with short-id 'gh' and linda wrote a "global home" repository with the same short-id, do we just tell johnny or linda to change? :) 19:06
Progress: github.com/MadcapJake/rakudo/commi...840c42779c 19:11
nine_ Essentially that was the idea. It's like the scheme part of URIs. 19:13
MadcapJake so if we only allow one repo to a given short-id, I could revert back to single-files in the repositories directory, right? 19:53
20:22 pnu__ joined, MadcapJake_ joined
nine_ one module but different versions 20:22
MadcapJake_ what would be the point of supporting multiple versions of a repo though? 20:27
MadcapJake nine_: Let's say you install a new CUR, wouldn't you want it to replace the old CUR? What situation would you want to utilize a previous CUR version's api? 20:50
nine_ When you uninstall this CUR, wouldn't you want to utilize the older, still installed version? 21:07
Maybe that's the reason for uninstalling in the first place: the new version doesn't work right.
MadcapJake ok i can see that 21:11
perlpilot what does it mean to "version a CUR"? 21:13
MadcapJake well a CUR in that light would be just like any other module 21:16
this work I'm doing is wrt custom CURs
perlpilot just reading the last few lines here, I get the impression that you could use versioned CUR to implement a set of poor-man's local::lib sandboxes 21:20
MadcapJake not familiar with local::lib, could you elaborate? 21:21
mst p3rl.org/local::lib
MadcapJake doesn't perl 6 already have -Ilib and `use lib 'lib'` for this kind of purpose? 21:22
mst basically "about eight years ago, mst got bored of explaining how to get perl to install to and load from an extra directory tree on #perl and managed to boil it down to 4 env vars ... then wrote a module to generate them"
...
no, those are equivalent to the perl5 -Ilib and 'use lib'
MadcapJake oh :P
mst shockingly enough
MadcapJake how are they different? 21:23
mst huh? -Ilib and 'use lib' affect @INC or equivalent 21:25
local::lib affects @INC, and $PATH, and the behaviour of module installation 21:26
did you read the docs for local::lib when I linked them? :(
MadcapJake mst: yep :) skipped the bootstrapping part though :P
mst that's ok
everybody does, then they complain they don't have local::lib installed already so clearly this is useless 21:27
MadcapJake I'm not a perl 5 programmer so this is a little hard for me to discern
mst ok, so, basically, PERL_MB_OPT and PERL_MM_OPT are specifying "which CUR to *install* into"
whereas @INC is "which CUR to *load* things from"
then the $PATH thing is because I don't have shim scripts and wanted something that was actually simple and debuggable by sysadmins 21:28
MadcapJake ok this is awesome, yes this is exactly what my custom CUR work would allow 21:29
perlpilot excellent
MadcapJake right now perl 6 has two CURs: filesystem (CURFS) and installation (CURI). CURFS doesn't have the means to install or uninstall and is how -Ilib and use lib work (seems like this is the same as Perl 5). Whereas CURI uses a special filesystem database but allows installs and uninstalls (though you really can pick a location for this via RAKUDO_PREFIX) 21:32
(there are three other CURs actually, AbsPath, Perl5, and NQP) 21:33
anyways, I am working on a CUR for GX which is a language-agnostic package manager that utilizes the P2P IPFS protocol. 21:35
mst yeah, personally, I would like to have a read-only ::Installation and then a subclass that does the installs 21:47
and RAKUDO_PREFIX for CURLI is basically equivalent to the local::lib INSTALL_BASE bits
21:50 Kassandry joined
mst MadcapJake: does that make local::lib make a bit more sense? 21:54
22:16 sufrostico joined 23:08 lizmat joined 23:33 lizmat_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!