|
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 February 2016. |
|||
|
06:06
llfourn joined
07:05
domidumont joined
07:08
domidumont joined
|
|||
| nine_ | mst: actually I punted the hardest question on what to actually allow in DependencySpecifications. I just write $spec.perl into the .deps file and EVAL it later. I just figured it will be a lot easier to test ideas for serialization formats against a working reference implementation. | 07:45 | |
|
08:19
TimToady joined
|
|||
| El_Che | it is OK to add additional information to the META6.json file? Maybe "namespaced" prefix_something: "blah" | 09:19 | |
| lizmat | In my mind it is, as the set that is used for installation is the "required" set only | 09:25 | |
|
10:35
JimmyZ_ joined
|
|||
| El_Che | thx | 10:48 | |
| nine_ | The Perl 5 toolchain gang has a discussion about META files and that they do contain much information that's not necessary for installation. Particularly there are issues with Unicode characters in author names and some tools that do not cope too well with that. | 11:54 | |
| Maybe our takeaway from this is, that there will be non-Perl6 tools that want to read and process our META files and we always should keep them in mind. | 11:55 | ||
| Particularily worrying is that our META files are completely unversioned. | |||
| llfourn | +1 for the possibililty of versioning META files like we version the spec | 12:06 | |
| maybe we could make a JSON schema json-schema.org/ as part of the spec? | 12:08 | ||
|
13:06
sufrostico joined
13:10
z8 joined
15:18
sufrostico joined
|
|||
| ugexe | perl5 already versions their meta | 15:35 | |
| they use meta-spec 2 right now i believe | 15:36 | ||
| any meta keys you have in your meta will get installed, not just the subset it knows about. i attach arbitrary meta information that may be used later this way | 15:37 | ||
| it would probably be best if there was a specified field for such things though | 15:56 | ||
| that way a 3rd party CUR can make more assumptions about any keys it may want to add to the META6 format it understands | 15:57 | ||
|
16:02
hoelzro joined
16:24
hankache joined
|
|||
| xdg | Perl 5 META files aren't installed by default, so don't draw any conclusions. Spec allows "x_" for any custom keys and those are widely used e.g. "x_contributors" | 16:25 | |
| Requiring "x_" insulates the spec from future collisions, but we then have a situation where tools will need to support "x_foo" even if "foo" becomes an official key. | 16:26 | ||
| So, possibly, "x_" is an antipattern. But then you have to lock things down or let it be the Wild West. | 16:27 | ||
|
17:01
sufrostico joined
18:06
Kassandry joined
18:29
domidumont joined
18:34
sufrostico joined
18:48
llfourn joined
|
|||
| mst | nine_: eh, if that's working, I'm ok with it. it has the nice advantage that at some point we can yank that data from an installation of 'every module we can find' and that tells us what people are actually using and *then* we can figure it out from there | 18:48 | |
|
19:06
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 | ||
|
19:31
flussence joined
23:41
lizmat joined,
ugexe joined
|
|||