resources => {
   repository  => {
      type => 'private',
   },
}

The "generated_by" in the MYMETA file reflects what generated the META
file but there's no information about what generated the MYMETA file.

Both the tool which generated the MYMETA and what it came from are
useful.  I suggest that the MYMETA file copy generated_by to
generated_from and fill in generated_by with its own information.

    generated_from: ExtUtils::MakeMaker version 6.5502
    generated_by:  ExtUtils::MakeMaker version 6.5709,
CPAN::Meta::Converter version 2.110580

This follows the spec's description of generated_by as "the tool that
was used to create this metadata".

$ dzil authordeps
Dist::Zilla::Plugin::Git::Push
Dist::Zilla::Plugin::MetaResources
Dist::Zilla::Plugin::AutoVersion
Dist::Zilla::Plugin::CheckExtraTests
Dist::Zilla::Plugin::CheckChangesHasContent
Dist::Zilla::PluginBundle::Filter
Dist::Zilla::Plugin::MetaNoIndex

Your configuration file couldn't be loaded.
Can't locate Dist/Zilla/PluginBundle/RJBS.pm in @INC

One, a "intent: personal" flag for distros that need to be public, but
are generally intended for personal use.  Examples of this would be the
Task::BeLike:: and Dist::Zilla::PluginBundle::[AUTHOR] distros.  This
could then be used by CPAN/MetaCPAN to push these kind of distros at the
bottom.

For now, I think I'll push for x_intent usage.

Two, a concept of "symlinks" or "stub META files".  For example, a
property like:

{ alternates: { "::Author::Foo" : { "replacement_for" : [ "::Foo" ] } } }

This was in reference to similar conversations about moving
Dist::Zilla::PluginBundle::[AUTHOR] modules to a
Dist::Zilla::PluginBundle::Author::[AUTHOR] namespace.  These kind of
META properties could even be put into real distros.  Just as long as
cpan/cpanm/cpanplus is smart enough to know that if it tries to grab
::Foo, it should really be grabbing ::Author::Foo.

This sort of thing would really fix a lot of problems related to moving
public modules, instead of putting some DEPRECATED stub module in there
for years, just to rename something.  This is also better than trying to
set the logic for this within Perl's local package structure itself.

use strict;
use warnings;

use CPAN::Meta::Requirements;

my $conflicts;
my $requires;

{
    $conflicts = CPAN::Meta::Requirements->new();
    $conflicts->add_string_requirement('Foo', '5.000');
}
{
    $requires = CPAN::Meta::Requirements->new();
    $requires->add_string_requirement('Bar', '5.100');
}

if ( $conflicts->accepts_module('Foo', '5.100') ) {
    print "5.100 conflicts!\n";
}
if ( $requires->accepts_module('Foo', '5.100') ) {
    print "Foo 5.100 satisfies isntall\n";
}

#5.100 conflicts!
# Foo 5.100 satisfies install

No doubt this is the wrong place for this, but I'm not sure what mailing
list (or elsewhere?) would be best, instead, so, better here than
nowhere, for now:

    (from #metacpan, 2012-09-23)
    10:08 < ether> ... thoughts on a meta field indicating where to send
failed automated tests?
    10:08 < ether> i.e. right now, cpantesters just mails to who last
released the dist, who may or may not be the primary author
    10:09 < ether> it might be more useful for some dists to have an RT
ticket opened automatically
    10:09 < ether> or an email to go to some other place entirely
    11:29 < mike> project mailing list or something
    11:29 < mike> I like it.

I've released a lot of dists recently that I didn't write and don't even
know the internals of very well, but because I was the last releaser, I
get all the failed cpantesters reports. If I don't now how to resolve a
particular issue, I just open an RT ticket for it to give the other
maintainers an opportunity to see it, but for dists with a large number
of maintainers, it would be more efficient to simply have a ticket be
opened directly and automatically. Likewise some large projects use
github issues to coordinate their task list, and it would be convenient
for them to have failed test reports to be channelled into that pipeline.

Is there a formal process for proposing additions to the meta spec?

This is just a wish list item. I'd like a way to build up a META data structure without knowing 
anything about the data structure itself. Something like:

$meta->add_to_provides( ... );
$meta->add_to_configure_requires( ... );

$meta->set_perl_version( ... );

$meta->set_repository( ... );

I'm not suggesting a particular interface, and there's probably a clever way to take the spec and 
automatically provide the interface.

Some of this relates to my work to convert legacy scripts into distributions.

$cmc->convert_fragment( from_version => "1.4", to_version => "2" );

Subroutine UNIVERSAL::TO_JSON redefined at [path/to/]CPAN/Meta/Converter.pm line 39

When the original YAML looks like

optional_features:
  opt_csv:
    description:        Provides parsing of CSV streams
    requires:
      Text::CSV_XS:                        0.69
    recommends:
      Text::CSV:                           1.21
      Text::CSV_PP:                        1.29
      Text::CSV_XS:                        0.95
  opt_excel:
    description:        Provides parsing of Microsoft Excel files
    requires:
      Spreadsheet::ParseExcel:             0.26
      Spreadsheet::ParseExcel::FmtDefault: 0
    recommends:
      Spreadsheet::ParseExcel:             0.59
  ⋮

The internal structure will look like

{   opt_csv          => {
        description      => 'Provides parsing of CSV streams',
        x_recommends     => {
            'Text::CSV'      => '1.21',
            'Text::CSV_PP'   => '1.29',
            'Text::CSV_XS'   => '0.95'
            },
        x_requires       => {
            'Text::CSV_XS'   => '0.69'
            }
        },
    opt_excel        => {
        description      => 'Provides parsing of Microsoft Excel files',
        x_recommends     => {
            'Spreadsheet::ParseExcel' => '0.59'
            },
        x_requires       => {
            'Spreadsheet::ParseExcel' => '0.26',
            'Spreadsheet::ParseExcel::FmtDefault' => 0
            }
        },
    ⋮

Passing the complete meta structure through

     my $yml = CPAN::Meta::Converter->new ($jsn)->convert (version => 
"1.4");

will now cause several errors like

Odd number of elements in anonymous hash at /pro/lib/perl5/
site_perl/5.16.0/CPAN/Meta/Converter.pm line 462.

followed by

Failed to downconvert metadata to 1.4. Errors:
Expected a map structure from string or file. (optional_features -> 
opt_csv -> build_requires) [Validation: 1.4]
Expected a map structure from string or file. (optional_features -> 
opt_csv -> requires) [Validation: 1.4]
Expected a map structure from string or file. (optional_features -> 
opt_excel -> build_requires) [Validation: 1.4]
Expected a map structure from string or file. (optional_features -> 
opt_excel -> requires) [Validation: 1.4]
⋮

Caused in function _downgrade_optional_features

by

    $features->{$name} = {
      description => $origin->{$name}{description},
      requires => _extract_prereqs($origin->{$name}
{prereqs},'runtime','requires'),
      configure_requires => _extract_prereqs($origin->{$name}
{prereqs},'runtime','configure_requires'),
      build_requires => _extract_prereqs($origin->{$name}
{prereqs},'runtime','build_requires'),
      recommends => _extract_prereqs($origin->{$name}
{prereqs},'runtime','recommends'),
      conflicts => _extract_prereqs($origin->{$name}
{prereqs},'runtime','conflicts'),
    };

resulting in _extract_prereqs () returning empty lists causing illegal 
initialisation

rabbit@Ahasver:~/devel/dbic$ grep '^license' -r META.yml 
license: Perl_5

rabbit@Ahasver:~/devel/dbic$ perl -MCPAN::Meta::Validator -MDevel::Dwarn -MYAML=LoadFile -e 'my $v = CPAN::Meta::Validator->new(LoadFile("META.yml")); Dwarn [ $v->is_valid ]; Dwarn [ $v->errors]'
[
  ""
]
[
  "License 'Perl_5' is invalid (license) [Validation: 1.4]"
]

runtime
        The runtime phase refers not only to when the distribution's
contents are installed, but also to its continued
        use. Any library that is a prerequisite for regular use of
this distribution should be indicated here.

I believe most of the use of 'runtime recommends' out there on CPAN
refers to the "regular use of the distribution". They also intend what
we now describe as 'suggests' but that's probably because it wasn't
there in META 1.x.

However, because the spec says the runtime prereq has to be satisfied
in the installation time, it could easily create a circular
dependency, as you can see in the list:
https://gist.github.com/miyagawa/5516279

Given the size of CPAN, that's not a lot, but i feel like there might
be a need for a separate phase other than runtime, to specifically say
the regular use of the module, not to cover the
build/test/installation time requirement.


--
Tatsuhiko Miyagawa

19:44 < garu> is there a documented standard way of telling cpan that a certain dist is unsupported on that OS?
19:45 < garu> xdg: cpan::reporter just parses the harness output looking for either 'No support for OS' or 'OS unsupported'
19:45 < garu> (from any .t file)
19:45 < garu> but that seems... fragile :)
19:49  * garu wonders if there is a $city consensus on this somewhere
20:01 <@ether> garu: Dist::Zilla::Plugin::AssertOS
20:01 <@ether> or copy what it does, via Devel::CheckOS, if you don't use Dist::Zilla
20:02 <@Getty> somethingsomething autodie::exception somethingsomething 5.18
20:03 <@Getty> somethingsomething cpanm autodie::exception => 2.20 somethingsomething perl -Mautodie::exception\ 999 => you have 2.13 somethingsomething... package Path::Tiny; use autodie::exception 2.14;... hmpf...somethingsomething
20:03 < crazed-> somethingsomethingelse no problems with it here at all somethingelse
20:06 < garu> ether: so... "no"? :)
20:07 < garu> ether: oh, I don't want to use it! I just want to know if there's a standard for that
20:07 < garu> ether: since I'm maintaining cpan::reporter and it checks for that, I wanted to make sure this is the proper way (or if there is a proper way, for that matter) :)

11:45 <@xdg> ether, open a ticket for it on CPAN-Meta and whenever we open up a CFP for v3,                 
             we'll get it discussed                                                                         
11:46 <@xdg> ether, for reference, the prior proposals can be seen here:                                    
             http://www.dagolden.com/index.php/519/list-of-cpan-meta-spec-proposals/                        
11:46 <+dipsy> [ List of CPAN Meta Spec Proposals | David Golden ]                                          
11:46 <@xdg> And the results here:                                                                          
             http://www.dagolden.com/index.php/538/summary-of-cpan-meta-spec-public-discussions/            
11:46 <+dipsy> urgh. long url. Try http://tinyurl.com/laxodpj                                               

05:47 < clintongormley> heya all, to mark a module as deprecated, i should just add it into the name and add a big DEPRECATED warning in the DESCRIPTION?  Anything else?
09:31 < kentnl> ether: actually, might want to tack that on to your lyon talking point list, I don't know of a formal way to mark anything deprecated in META.*, there's only POD side conventions 
09:33 < ether> good point
09:33 < ether> there's release status = stable/testing right now; perhaps make that a trinary? or a separate flag
09:40 < kentnl> I'm feeling it should be independent atm, because stability is a function of the release ( ie: Arity = 1 ), but deprecatedness is a function of the dist ( ie: Arity = all N ) 
09:41 < kentnl> Though thats probably one reason why not to include it perhaps, because its extending beyond the scope of the meta it pertains to *shrug* 
09:41 < kentnl> I can see however  deprecated => { Module::Name } being of use though
09:42 < kentnl> ie: "In this distribution, at this release, the following modules are no longer recommended to be used" 
09:42 < kentnl> there's less temporal inference there.
09:46 < kentnl> just the "property of this release" vs "Property of all releases" is something that might confuse somebody really.
09:46 < kentnl> Would hate for people to go "well, I'll just not upgrade then, and then it wont be deprecated!" ;) 

Most of the toolchain respects 'perl' in a prereqs hash and treats it differently than other modules.

We should define desired semantics for perl with version ranges or perl that shows up in requires (e.g. 5.8) and recommends (e.g. 5.16).

I've come across some METAs that use the British spelling of "license"
as "licence".  These will fail the CPAN::Meta conversion process.   I
realize this is a slippery slope, but do you think it would make sense
to support the alternate spelling?

Can't merge attribute release_status at <some line in Dist::Zilla>

The Meta spec should restrict the set of characters allowed.

I propose to restrict the characters to the list defined in the XML
specification.
http://www.w3.org/TR/REC-xml/#charsets

Rationale:
Control characters may cause unexpected things in the CPAN infrastructure.
See for example bug RT#58038 
https://rt.cpan.org/Ticket/Display.html?id=58038

-- 
Olivier Mengu? - http://search.cpan.org/~dolmen/ http://github.com/dolmen/

sub identifier {
    my ($self,$key) = @_;
    if(defined $key) {
        return 1    if($key && $key =~ /^([a-z][_a-z]+)$/i);    # spec 2.0 defined
...

11:07 < ribasushi> haarg: speaking of indirect - can we have strictures *not* list the 3 XS-es as prereq?
11:08 < mst> hrm. it should at least respect PUREPERL_ONLY
11:08 < ribasushi> no
11:08 < ribasushi> it has shrinking requires
11:08 < ether> so how did this conversation happen to come up again? did anything specific happen to precipitate it?
11:08 < ribasushi> i.e. META says one thing, MYMETA says less
11:08 < ribasushi> this fucks up static analyzis big time
11:08 < mst> oh. then the META generation is wrong.
11:08 < mst> META shouldn't list them, only MYMETA
11:09 < mst> that's a Makefile.PL bug then
11:09 < mst> I did a dance for Moo so MRO::Compat doesn't show up in META
11:09 < mst> strictures should do the same dance
11:09 < mst> sorry, 'list as prereq' to me implied PREREQ_PM, not "our META generation is buggy"
11:09 < haarg> i'll work on that
...
16:00 < haarg> ribasushi: what actual problems does having the extra prereqs in META cause?  i'm going to change it, i just wasn't aware that it would cause issues.
16:01 < ether> they're just recommendations aren't they?
19:45 < haarg> ether: currently strictures attempts to have them as hard requirements if you have a compiler available
19:46 < haarg> but that results in them being listed as requirements in META
19:47 < haarg> but dynamic_config is still true, so i'm interested in what problems that results in
19:48 < haarg> afaik there isn't anything in the spec saying "listed prereqs are hard requirements, but have to run Makefile.PL to get the rest"
19:48 < haarg> so either i'm missing something about the spec, or there's a client misbehaving in a way i wasn't aware of
22:07 < ether> haarg: that's what dynamic_config is for
22:08 < ether> don't list them as requirements in META. write code in Makefile.PL to add them if a compiler is available, and add dynamic_config => 1 to META_MERGE
22:08 < ether> dynamic_config => 1 just means that the META requirements are not final, but they should be a subset of the final list, not possibly a superset
22:09 < ether> or some static analyser will go "oh I can't fulfill the minimum requirements in META; I won't bother trying to see what else gets added in MYMETA"
22:18 < haarg> what static analyser though?
22:21 < haarg> "This field should be set to a false value to indicate that prerequisites included in metadata may be considered final and valid for static analysis."
22:21 < haarg> nothing about subset vs superset
00:33 < ribasushi> haarg: META for downstream packagers is "what is he absolute minimum required to make this work"
00:33 < ribasushi> dynamic_config != 0 only implies "there may be more added"
00:34 < ribasushi> haarg: also things that rely on static metacpan eyeballing will get confused, again given META (not explicitly, but historically) implies "absolute minimum"
00:34 < ribasushi> we should clarify this in Lyon perhaps, my understanding is that META can not shrink
06:44 < leont> ether, haarg, ribasushi: the spec is awfully silent on whether it should be minimal or not, though I agree minimal is the sane approach that people have been drifting to in the past couple of years
08:33 < ribasushi> leont: right I am aware it is silent, but since it is actively used in static analysis it makes no sense in any other way
08:59 < haarg> apparently you can't have dynamic prereqs aside from build/test/runtime requires with EUMM
09:01 < leont> Why not?
09:01 < haarg> because META_ADD/META_MERGE are ignored if a META file exists
09:07 < leont> Right, that kind of makes sense
09:07 < leont> MB should have the same behavior
09:30 < ether> it would be good to get clarification in the spec re meta being an absolute subset of the final list
09:31  * ether makes a note.
09:33 < ether> what does a META file existing have to do with build/test/runtime specifically?  are you drawing attention to the lack of configure and develop in that list?

  $mgr = CPAN::Meta::Merge->new(default_version => "2");
  $merged_meta = $mgr->merge($cpan_meta_obj1, $cpan_meta_obj2);

Can't locate object method "as_string_hash" via package "CPAN::Meta" at \\
.../perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2/CPAN/Meta/Merge.pm line 172.

As mentioned on Twitter, with that old Perl CPAN::Meta passes all tests, but fails to install any files: https://gist.github.com/wchristian/c197c7101cffef331758

According to discussion in #toolchain (btw, where's your bnc?), this is because @INC on Perls <= 5.10.1 lists core lib before site lib, and one comment made was:

15:58:08 (ilmari_) hence dual-life modules having to do INSTALL_DIRS=perl

It'd be nice if the meta contained some mandatory or optional metadata on 
whether or not it's an XS module and has to be rebuilt on upgrade to a 
incompatible perl ABI.

with CPANPLUS::Dist::Arch this could also be used to tell whether we 
should package it as arch=('any') (what we use for pure perl) or 
arch=('i686' 'x86_64'). I'm sure other distributions could find use for 
it as well.

just a suggestion

I would love to have some type of "x_icon" META attribute that either points to an image file within the distribution or a URL that is the icon for the distribution.  Displaying that image on metacpan.org or stratopan.com would help give Perl modules a bit more pizzaz (something that software libraries typically lack).  You could even go a bit further and specify the required size and format of the image.