Re: Why do we keep using META.json for stuff that has nothing to do with installation

[Aristotle Pagaltzis]

* 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 // 

Re: Why do we keep using META.json for stuff that has nothing to do with installation

[David Golden]

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  Twitter/IRC/Github: @xdg

Re: Why do we keep using META.json for stuff that has nothing to do with installation

[Kent Fredric]

On 28 February 2016 at 00:06, Peter Rabbitson  wrote:
>  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.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Why do we keep using META.json for stuff that has nothing to do with installation

[Peter Rabbitson]

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.


 why do we continue to keep trying to stuff unicode into meta 
in the first place?
 the authorship information has nothing to do with 
installation time

 we use it for display purposes only (e.g. metacpan)
 anyone considered META.meta or similar?
 I am not even talking about 5.8 at this point - on windows 
having unicode in meta will be forever a pain
 ( due to Xmake proliferation and various backwards compat 
kludges which leak META into the generated makefile )
 I dunno, my stuff only ever handled it in the first place because 
ilmari complained at me
 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

 [ META.json - metacpan.org ]
 hmm. I bet the original goal was for the META file to be fed into 
packaging systems
 right, which was in another era more or less ( no cpanm, no 
metacpan, no perl-pkg groups etc )
 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