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 4 July 2017.
00:09 lizmat 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
07:23 domidumont joined
ugexe nine: how would I write a dependency for a version range of rakudo (by-vm.version ?) 16:49
nine ugexe: that's a dreaded topic, isn't it? 16:51
ugexe m: say $*VM.version.Str.substr(0, 7); # it would be easy enough if there was access to a substring 16:52
camelia 2017.06
nine But that's MoarVM's version? 16:54
ugexe there is one for rakudo too though, but its the same deal i think 16:55
16:56 domidumont joined
ugexe depends => runtime => [ { :name<rakudo>, :from<native>, hints => { "by-perl.compiler" => { ...? } } ] 16:57
nine Is this a workaround for us failing to release a 6.d some time this decade? 16:58
ugexe well for me to remove all the hacky proc workarounds for pre-2017.06 I have to make changes that wont work on older rakudo. something like this could allow zef on older rakudos to not upgrade past what they are capable of using 17:00
mst surely you could write a slang that gives you compiler-version-based ifdefs 17:01
nine Maybe what we actually need is this: metacpan.org/pod/CPAN::Meta::Spec#conflicts1 17:24
Since while you don't know on which versions of which Perl 6 compilers the code will work, you do know that on some very specific versions of rakudo it will not.
ugexe you still need a range 17:26
which is what i'm wondering how we declare in the hints 17:27
sure, but i'd like to avoid that route for as long as possible - panda would just version itself after rakudo versions for instance - to avoid all the cruft that leaves behind 17:31
re: ifdefs / wrappers
nine That would be metacpan.org/pod/CPAN::Meta::Spec#...ion-Ranges 17:32
ugexe but how to write it as a *dependency hint* 17:33
we would have to define a "version" key means turning it into a version object 17:34
er, you're saying to use that in conflicts, but it would still need to be written in that dependency hint format I assume 17:35
nine In your case it's not just a hint, is it? You know the code will not run on those rakudo versions.
ugexe thats the case no matter where i put it 17:36
but this is mostly for someone upgrading zef 17:37
their old version of zef would check the hints, see it can't run on that native depends (missing), and look for a version it can 17:38
nine I wonder if this would warrant a whole new section in the META file. Thing is, if we add a way to positively depend on some compiler version, there will in some future be a compiler that has to pretend to be rakudo to be able to run software. Because people are lazy.
If there's only a way to exclude certain versions of specific compilers, newcomers won't have any issues. 17:39
Btw. I guess nothing we come up with now will help users of old zef versions trying to upgrade beyond their rakudo's capabilities, because those old zef versions won't understand what we do anyway. 17:40
ugexe true. in my case i depend on rakudo::internals so its not as much an issue 17:41
nine Unless we specifically break their META parser...
Then they won't be able to install the new zef, but also won't tell the user why :)
ugexe not true. Build.pm can be used. what we cant do is have zef automatically upgrade to the latest they can use
oh that 17:42
nine On a slightly different topic: I think we could drop the old Distribution compatibility crap in rakudo. AFAIK only panda used it as a class and panda doesn't seem to work anymore anyway. 17:44
ugexe i suppose if zef sent user agent strings the ecosystem could choose what dists to display. essentially if no user agent is sent it would remove the *new stuff* from the meta data and apply whatever logic it can 17:45
nine Perfect backwards compatibility was a pipe dream anyway and we've broken it many times already.
ugexe: sounds like a lovely workaround where we stay in control :) 17:46
ugexe another more interesting problem i'm facing is how to treat a distribution that is both Distribution::Tar but also Distribution::Remote. the naive approach is just to get the Distribution::Remote to then build a Distribution::Tar from locally, but i'd like to handle it such that it can be done A) without creating a local file B) where the ::Remote logic can be reused with say ::Unzip and ::Tar can be 17:54
reused locally
so something like `Distribution::Tar but Distribution::Remote(&logic-for-fetching)`? 17:56
or maybe the other way around? I suppose it could possible be both tar'd and zip'd for some insane reason 17:58
another design problem i'm having is with `Distribution.meta<name|ver|auth>` and remote distributions. ideally i'd be able to do `Distribution::Remote::GitHub.new(:url<...>, :meta(:name<Foo::Bar>, :ver<0.1>)).meta<name>` without it having to connect to the url to get the meta data (because we already assume to know the name), but doing so on `.meta<name>` itself (instead of some `method name { $.name 18:09
// self.meta<name>> }`)
while still having say .meta<provides> or .meta<depends> fetch the meta data since we do not have any such hash keys defined in %.meta 18:10
so probably a Proxy object?
something like `has %.meta but role :: { multi method AT-KEY($key where {not defined %.meta<< $key >>)}) { self = self!fetch-meta_($url); nextsame() } }` 18:15
even better if it could warn if any values change from a undefined value to a defined value - e.g. this Distribution was created with :version<0.1.0> as declared by the ecosystem, but the meta data was actually fetched the :version was changed to :version<0.1.9> 18:22
s/from a undefined/from an already defined/ 18:23
nine I'd probably write someting doing the Associative role and delegating all but the special keys to the contained meta data hash. 18:26
On that note, Distribution.meta should actually not return a Hash but an Associative, too. 18:28
ugexe m: class Foo { has %.hash handles <AT-KEY>; multi method AT-KEY($key where {$_ eq 'foo'}) { say "Got foo"; nextsame(); }; } # this is what I was trying 18:29
camelia Resource temporarily unavailable
nine And all implementors should return a Map rather than a Hash
ugexe ===SORRY!5=== Error while compiling <tmp>â¤Package 'Foo' already has a method 'AT-KEY' (did you mean to declare a multi-method?)
if those all serialize to json the same then i don't see a reason not to return something else 18:32
i guess the spec only returns .meta to return a hash though, so the json bit is irrelevant
only expects^
another breaking change we might consider is %?RESOURCES returning a IO::Handle (or a fake one like .content) instead of an IO::Path - right now you can have a Distribution that installs all source files using data from a socket but you *have* to have resources stored locally because they only give you a path 18:36
github.com/ugexe/Perl6-CompUnit--R...r.pm6#L113 - here is an example where CUR::Tar has to extract the resource files from the archive to some tmp location whereas the source files bytes are piped directly from tar 18:38
nine ugexe: the lovely thing about %?RESOURCES is that we can actually change it in a lexical scope :) So we can stay backwards compatible with 6.c in that case :) 18:39
ugexe how so? 18:40
nine It's implemented in Perl6::Actions which creates the Distribution::Resources object backing it. At that point it can do things differently depending on the lexical scope's current language version, so instead it could create a Distribution::Resources::LikeItShouldHaveBeen object. 18:43
ugexe i think it would mostly work if it returned the Fake::Handle that stringified using its :path attribute 18:45
depends on the differences between IO::Handle and IO::Path methods I guess
nine Why stringify to a path at all? 18:47
ugexe so `require %?RESOURCES<foo>` still works 18:48
(i think that works anyway) 18:49
nine That sounds terrible?! 18:50
Why would we want to support that?
ugexe not saying we do, this is just from a backwards compatible perspective 18:51
nine Which we don't have to use, as 6.c code will still get the old path based %?RESOURCES
ugexe right, i mean a backwards compatible change that can also implement the new functionality *in 6.c* 19:04
not that I care if it waits till 6.d
gist.github.com/ugexe/8817d4244fe1...2026fb8a0d 19:50
20:24 FROGGS joined 23:02 b2gills 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!