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 12 January 2016.
00:22 llfourn joined 01:23 llfourn joined 02:22 llfourn joined 02:48 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:23 llfourn joined 04:24 llfourn joined 05:09 llfourn joined
nine sjn: pong 07:37
08:08 FROGGS joined 09:27 leont joined 11:44 FROGGS joined 14:14 domidumont joined 14:57 domidumont joined
nine What do toolchain people think about moving Test.pm from the CORE distribution out into the ecosystem? Rakudo could still come with a Test.pm for its make test and make spectest, but no longer install it by default. 15:48
moritz -1
tony-o nine++
moritz I use Test.pm in every single one of my projects, and I'd hate to install a dependency 15:49
users can still distribute their Test::More, Test::Less, Test::Fancy, Test::Whatever, just like in p5
nine With it being an ecosystem module, it would be much easier to upgrade or to require a specific version. There's nothing that actually requires us to bind Test's version to the Perl 6 version.
tony-o i think it's more common now than when p5 came about
nine lizmat has to revert an otherwise harmless fix to Test.pm because it breaks a spec test for unknown reason. 15:50
tony-o actually, i guess, i'm with moritz - most languages don't have a supercedes mechanism
moritz can we make it dual-lived at least?
[Coke] we could try to fix the breakage, btw.
moritz installed with core, but overridable from panda
[Coke] (dual lived) aaaaaigh
that won't address nine's concern, and will add complexity. -1 15:51
nine Of course we will try to fix this, but the principle remains. Having Test in the ecosystem would allow for quicker turnarounds with for example added features. Waiting for a year for a language release to be able to use a new test function sucks.
tony-o i like the idea of removing it from core. 15:52
nine Especially since people who know Perl 5's test frameworks think Test.pm is severly outdated architecture wise
tony-o i can see mortiz's point and right now it makes sense to leave it in core or every module will fail testing, currently and all METAs will need updated 15:53
[Coke] also it changes what 6.c means. we'd need a 6.c.1 or so
tony-o `green` behaves more like node's mocha
which is friendlier for async things 15:55
nine [Coke]: we may still get away with removing it even from 6.c by having panda and zef add it automatically to a module's test-depends until all META files have been updated
moritz nine: I do test modules without panda
nine But we may as well remove it in 6.d
moritz: but installing one ecosystem module once per Perl 6 installation doesn't sound that bad, does it? 15:56
[Coke] there are Test tests in 6.c; I think we're on the hook to include it for now
nine moritz: keep in mind that we no longer loose installed modules on rakudo upgrades
sjn nine: are you going to the easter hack thing in Salzburg?
nine sjn: have never heard about that?
PerlJam nine: we wouldn't remove it in 6.d would we? We'd deprecate it and remove in 6.e. right?
tony-o PerlJam++
sjn nine: Easterhegg 2016 - www.easterhegg.eu/category/easterhegg-2016/ 15:57
[Coke] or dep in 6.c.1 and remove in 6.c.2
moritz nine: does panda still work after a rakudo upgrade? 15:58
nine moritz: yes it does
moritz nine: then maybe it's no as dire as I imagined it :-) 15:59
nine moritz: only the first startup after a rakudo upgrade is a little slow
PerlJam [Coke]: or that (though, I'm not clear on the timing of these point releases. If they happen too quickly, then I'm against using them for a deprecation cycle) 16:00
nine PerlJam: I'm not sure if it would warrant a deprecation cycle (we're talking about a year or more there!), as it's really just a "panda install Test". And our installers may even do that automatically.
PerlJam nine: I dunno. I worry a bit about setting precedent here. Would we do the same thing if it were IO::Socket::Async or one of the other core modules? 16:03
[Coke] PerlJam: you mean like the one that we're already trying to remove in nom? 16:04
PerlJam [Coke]: Are you referring to IO::Argfiles? 16:05
[Coke] I don't remember which one it was.
nine IO::Socket::Async is no module but part of the setting and a part of the language that's tested by the spec test suite. We've been shipping a Test.pm as convenience. It's not integrated at all with the rest and is really the odd man standing out. 16:07
lizmat Pod::To::HTML ?
sorry, Pod::To::Text ?
PerlJam nine: I guess if there are no tests in roast/6.c that test Test.pm6, then removing it should be harmless. 16:09
(and I probably should have put scare quotes around harmless too) 16:10
flussence um, don't 100% of the tests in roast also test Test.pm6 by definition, since they use its API? 16:11
ugexe i prefer having a basic tap emitter in core. i dont like the idea that it makes it harder to just test/install something without having a module installer
PerlJam flussence: I'd call that more of a side-effect.
nine > 80 ecosystem modules have already a test-depends: [ "Test" ] 16:12
ugexe that doesnt mean anything if its built in though
if i just want to clone someones project and install it now it means i have to also install Test.pm somehow or have a module installer installed 16:13
PerlJam ugexe: How would you install someone's project without a module installer? 16:14
nine I don't see how after going through all of rakudo's installation, getting one extra file from somewhere would be such a large barrier.
ugexe PerlJam: you can do it with a 1 liner using CompUnit::Repository
nine Rakudo is the compiler. Rakudo* is the usefull distribution with compiler + modules 16:15
PerlJam ugexe: and it'll auto-run any tests?
ugexe: and you can't tell it not to?
ugexe no, someone doing that would certainly run their own prove command manually as well 16:16
nine PerlJam: the one liner will install. It won't run tests or check dependencies.
ugexe right, but to write any testable module you would then *have* to have a dependency 16:17
maybe im in the minority but im not a fan of huge fragile dependency chains 16:19
nine Why should they be fragile?
ugexe they shouldnt but generally are
nine In Perl 6? We support and encourage people to depend on exact versions. 16:20
Aaand if that support is NYI it will probably come soon ;) 16:21
ugexe yes in perl6, and i also mean at the moment (in the future im sure this gets better as well)
PerlJam nine: I'm conflicted. I'm sympathetic to your argument, but I also think Test.pm6 should just Be There. We're going to use some test module anyway (and encourage others to do so); one should be included as part of any Rakudo installation. It's one of the things I really like about how we do things now. 16:28
Same goes for NativeCall btw. That one opens up huge possibility and should be part of any Rakudo install. Would you rather add that as a dependency to Inline::Perl5 or just rely on it being there? 16:33
autarch nine: big ++ on getting Test.pm6 out of core 16:35
PerlJam autarch: why?
autarch I'm really hoping that I can get this test stream stuff done soonish and have that be the basis for all future test modules
PerlJam: because if people use a module not based on this test stream code I'm working on then it'll make everyone's life harder down the road 16:36
PerlJam Hmm.
ugexe but it makes everyones lifes harder no matter what 16:38
you either make it harder for end users or you make it harder for people who write tests but plan on porting it to your stream format 16:40
nine PerlJam: I wouldn't mind a dependency in Inline::Perl5 at all and indeed, NativeCall has been an ecosystem module initially. It only got moved to core because most of its implementation is actually in the VM, so it's really tighly coupled to the compiler. The opposite of Test.
PerlJam: and Inline::Perl5 already has dependencies. No reason to avoid others. 16:41
ugexe: autarch's plan is to provide a Test module that has the same interface but uses the stream module for it's underlying implementation. So no pain for test writers. 16:42
tony-o that changes module installers method of installs
ugexe he just said it would be harder
tony-o test-depends: ["Test"] <- if test isn't available or installable, do you install the module or fail ?
i'm curious more about down stream
ugexe and this all seems like the type of thing supercedes/augments/emulates of s22 16:43
is meant to address
tony-o i brought that up earlier
PerlJam autarch: If we replace the exising Test.pm6 with one based on your test stream stuff, then it'll only make things harder for those people using a compiler that uses the existing Test.pm6 (which will be an ever-shrinking set) 16:45
nine tony-o: the test-depends question is independent of this dicussion. Inline::Perl5 for example has a test-depends: ["Test", "File::Temp"] as one of the tests uses File::Temp. 16:46
autarch is in a $work meeting, will catch up and respond when done
tony-o nine: i know it's separate, i'm curious what the thoughts are on that.
PerlJam autarch: but ... you've got me thinking about Test::* and interoperability and I think you've tipped the balance for me in favor of removing Test.pm6. 16:47
tony-o thank you for pointing out that it's separate
nine tony-o: I guess it should either ask the user or treat it as --notests
"it" being a missing test dependency
The "supersedes" angle is interesting. I wonder how using that feature would play out in real life. 16:48
[Coke] Note that we have S24-testing/ tests, but those seem to just be explicit versions of the implicit testing. I don't think they're actually testing TAP output or anything like that. 17:11
... crap, except 3-output.t, which is an explicit test for things like "does the output match "not ok" 17:12
so yes, we rely on TAP in 6.c
autarch PerlJam: I don't think it should be removed so much as removed from the docs and marked as "only use this internally for testing other core stuff" 17:15
nine Maybe this really would be a good test case for all the speculation about auths and supersedes and what not? A first step could be to just publish an updated Test module under different auth in the ecosystem and have some dists require that.
autarch nine: I could rename my stuff from Test::Stream to just Test if we think that's a good idea 17:16
nine autarch: my suggestion was not removing it entirely from Rakudo but no longer installing it by default.
autarch nine: right, that makes sense
nine
.oO(Test:auth<autarch>)
autarch I mean once my test stream is _done, reviewed, and documented_ I could rename it and we could put it into the ecosystem 17:17
with a "use Test" layer that works more or less exactly how the current one does, which I've already started writing as Test::Predicates in the repo
my repo, that is
17:40 leont joined
nine ugexe: Failed to copy '/home/nine/.zef/store/Inline-Perl5.git/resources/libraries/p5helper' to '/home/nine/rakudo/install/share/perl6/site/resources/42895AB4F020BCF13D71DFC98C445CD8CD3B4206.': Failed to copy file: no such file or directory 17:48
ugexe: with zef commit 499d47bda621c0bdd0e7b15f218d9e8f19fda247 17:51
18:02 Kassandry joined
ugexe strange, it works for me. i've been using install Inline::Perl5 after each commit to test too 19:56
nine I thought you'd have done that. Especially since you mentioned Inline::Perl5 in the commit message. 20:00
ugexe i wonder if it could have something to do with `$*VM.platform-library-name($0.Str.IO)` turning a basename only into an IO (which involves some $*CWD stuff) 20:05
nine same on my desktop 20:06
ugexe m: say $*VM.platform-library-name($*CWD.relative.IO) 20:40
camelia rakudo-moar 007f02: OUTPUT«"/home/camelia/lib..so".IO␤»
ugexe m: say $*VM.platform-library-name($*CWD)
camelia rakudo-moar 007f02: OUTPUT«/home/libcamelia.so␤»
ugexe other than the path differenence one returns a string and one returns an IO 20:41
lizmat ugexe: this won't be fixed before 6.d, I'm afraid 20:42
nine What's the difference to what panda's doing? The code looks quite similar ;) 20:45
ugexe passes in the absolute path instead of giving `.IO` a chance to get the $*CWD incorrect 20:47
well, what i want the path absolutified with (which might not be $*CWD) 20:48
21:07 hankache joined
ugexe travis-ci is able to install Inline::Perl5 with zef as well 22:01
travis-ci.org/ugexe/zef/jobs/10220...1771-L1774 22:02
22:26 leont 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!