FAQ
Copying a rhetorical question from #distzilla here, as it warrants a
wider audience. The background is yet another discussion of a kludgy
workaround where an installation with an older JSON parser is tripped by
unicode in META.json. Unicode that doesn't really serve any purpose for
an installing client.

<ribasushi> why do we continue to keep trying to stuff unicode into meta
in the first place?
<ribasushi> the authorship information has nothing to do with
installation time
<ribasushi> we use it for display purposes only (e.g. metacpan)
<ribasushi> anyone considered META.meta or similar?
<ribasushi> I am not even talking about 5.8 at this point - on windows
having unicode in meta will be forever a pain
<ribasushi> ( due to Xmake proliferation and various backwards compat
kludges which leak META into the generated makefile )
<mst> I dunno, my stuff only ever handled it in the first place because
ilmari complained at me
<ribasushi> https://metacpan.org/source/ETHER/Moose-2.1605/META.json
<--- 2600 lines, maybe 20 of them have to do with actual installation
and are expected to be read by *any* installer. The rest... is best
effort anyway, why not separate it and stay happy
<dipsy> [ META.json - metacpan.org ]
<mst> hmm. I bet the original goal was for the META file to be fed into
packaging systems
<ribasushi> right, which was in another era more or less ( no cpanm, no
metacpan, no perl-pkg groups etc )
<ribasushi> perhaps rethinking "Meta for end-user install purposes" and
"Meta for meta" would solve most of the recent repeated breakages by "oh
downstream doesn't like this new thingymagic"

Cheers

Search Discussions

  • Kent Fredric at Feb 27, 2016 at 11:14 am

    On 28 February 2016 at 00:06, Peter Rabbitson wrote:
    <ribasushi> perhaps rethinking "Meta for end-user install purposes" and
    "Meta for meta" would solve most of the recent repeated breakages by "oh
    downstream doesn't like this new thingymagic"
    +1

    I've been frustrated by this myself, the large amounts of auxilliary
    data just makes decoding the META needlessly complicated.

    And its amplified by Dzil needlessly documenting both install-relevant
    and not-install-relevant data in *both* META.yml and META.json ( esp:
    x_Dist_Zilla )

    I've even compensated by using a YAML generator filter that excludes
    x_* just to reduce my dist-size.

    And this seems even more relevant in a static-install future where all
    install is META driven.
  • David Cantrell at Mar 2, 2016 at 3:27 pm

    On Sun, Feb 28, 2016 at 12:14:36AM +1300, Kent Fredric wrote:
    On 28 February 2016 at 00:06, Peter Rabbitson wrote:
    <ribasushi> perhaps rethinking "Meta for end-user install purposes" and
    "Meta for meta" would solve most of the recent repeated breakages by "oh
    downstream doesn't like this new thingymagic"
    I've been frustrated by this myself, the large amounts of auxilliary
    data just makes decoding the META needlessly complicated.
    Does it? Absent bugs in the decoder, the extra data is just hash keys
    that you don't bother looking at. If you're not interested in, for
    example, knowing that Moose provides Class::MOP, don't look at the
    'provides' hash key.

    --
    David Cantrell | Minister for Arbitrary Justice

       Languages for which ISO-Latin-$n is not necessary, #1 in a series:

         Latin
  • David Golden at Feb 27, 2016 at 12:22 pm

    On Sat, Feb 27, 2016 at 6:06 AM, Peter Rabbitson wrote:

    Copying a rhetorical question from #distzilla here, as it warrants a wider
    audience. The background is yet another discussion of a kludgy workaround
    where an installation with an older JSON parser is tripped by unicode in
    META.json. Unicode that doesn't really serve any purpose for an installing
    client.
    The point of META is to describe distributions. The original META spec
    includes author name information. Names require international character
    sets. Other textual information (such as abstracts) could also contain
    international characters. The META 2 spec was specific about this in a way
    that the Meta 1.x specs were not. Because the primary purpose of META is
    to provide metadata, Unicode is essential to do that job correctly in a way
    that doesn't discriminate against non-English cultures.

    The more interesting question is "why are we using META for installation"
    -- and that we should split in two:

    (1) Why are we using META.* for installation?
    (2) Why are we using MYMETA.* for installation?

    We're using (1) because it was already there and was (theoretically)
    statically parsable to determine configure_requires. We're using (2)
    because it was convenient to follow an already known format from (1) rather
    than build yet another standard.

    If the problem with Unicode on certain Perls is with META, there's not much
    to be done at this point. Remember the days when users were constantly
    told "upgrade your M::B" or "upgrade your EU::MM" to fix various
    installation problems? It was a regular thing (and one of the things
    people hated about MB). Now, in relatively rare circumstances (and I think
    only on older Perls), someone has to upgrade their JSON parser. I can live
    with that.

    If the problem is with MYMETA, I have no problem having MYMETA strip out
    everything but absolutely essential fields – but then affected users have
    to upgrade their EU::MM/M::B, which is no better than having them upgrade
    their JSON parser, so I don't think it's worth the effort to do so.

    David


    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Aristotle Pagaltzis at Feb 27, 2016 at 2:01 pm

    * David Golden [2016-02-27 13:25]:
    The more interesting question is "why are we using META for installation"
    Because we can’t go back in time and make historical versions of EUMM/MB
    *not* use META for installation. End of line.
    If the problem is with MYMETA, I have no problem having MYMETA strip
    out everything but absolutely essential fields – but then affected
    users have to upgrade their EU::MM/M::B, which is no better than
    having them upgrade their JSON parser, so I don't think it's worth the
    effort to do so.
    But can we get to a situation where nobody needs to upgrade anything?

    That would be possible if we introduce a new file (e.g. INFO [^1]) for
    the things we currently stuff into META in spite of EUMM/MB never having
    cared about them. The data EUMM/MB do care about doesn’t really require
    Unicode, so if we only leave that data there, then historical versions
    of EUMM looking for META.json and parsing it using a broken JSON parser
    will work just fine, without the need to upgrade anything. So riba’s
    proposal has a benefit: it makes life better for users on old installs.

    Introducing a new file for install-time metadata (just because we once
    named another file META and would like to have that name continue to
    refer to all metadata about the distribution) would require everyone to
    upgrade their EUMM/MB to a version that supports this new file. This is
    much worse than making them upgrade their JSON parser. So might as well
    not do the separate files and just keep stuffing everything into META.
    That is, your line of thought here doesn’t seem to add up to any benefit
    for anyone compared to the current situation.

    It is true that using META for install-time data and then INFO (or some
    other name) for “general” metadata is annoying. But that’s the only way
    that it makes sense to separate the data into different files.

    [^1]: I don’t like `META.meta`. :-)

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Leon Timmermans at Mar 13, 2016 at 11:22 am

    On Sat, Feb 27, 2016 at 12:06 PM, Peter Rabbitson wrote:

    Copying a rhetorical question from #distzilla here, as it warrants a wider
    audience. The background is yet another discussion of a kludgy workaround
    where an installation with an older JSON parser is tripped by unicode in
    META.json. Unicode that doesn't really serve any purpose for an installing
    client.

    <ribasushi> why do we continue to keep trying to stuff unicode into meta
    in the first place?
    <ribasushi> the authorship information has nothing to do with installation
    time
    <ribasushi> we use it for display purposes only (e.g. metacpan)
    <ribasushi> anyone considered META.meta or similar?
    <ribasushi> I am not even talking about 5.8 at this point - on windows
    having unicode in meta will be forever a pain
    <ribasushi> ( due to Xmake proliferation and various backwards compat
    kludges which leak META into the generated makefile )
    <mst> I dunno, my stuff only ever handled it in the first place because
    ilmari complained at me
    <ribasushi> https://metacpan.org/source/ETHER/Moose-2.1605/META.json <---
    2600 lines, maybe 20 of them have to do with actual installation and are
    expected to be read by *any* installer. The rest... is best effort anyway,
    why not separate it and stay happy
    <dipsy> [ META.json - metacpan.org ]
    <mst> hmm. I bet the original goal was for the META file to be fed into
    packaging systems
    <ribasushi> right, which was in another era more or less ( no cpanm, no
    metacpan, no perl-pkg groups etc )
    <ribasushi> perhaps rethinking "Meta for end-user install purposes" and
    "Meta for meta" would solve most of the recent repeated breakages by "oh
    downstream doesn't like this new thingymagic"
    I'm pretty sure I've expressed exactly this sentiment before. Even
    Module::Build::Tiny, which is entirely dependent on the meta files for its
    operation, is using only 3 fields (name, version, prereqs); most other
    tools wouldn't even need the first two. A cpan client would also use
    dynamic_config, anything else is really either for pause or for metacpan &
    friends.

    I'm not sure changing this now is really going to make things better though.

    Leon

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedFeb 27, '16 at 11:07a
activeMar 13, '16 at 11:22a
posts6
users6
websitecpan.org

People

Translate

site design / logo © 2018 Grokbase