perl-toolchain-gang / cpan-meta Goto Github PK
View Code? Open in Web Editor NEWSpecifications for CPAN distribution META files
Specifications for CPAN distribution META files
There is no test coverage of "extra_mapping". An example in documentation would also be helpful.
https://rt.cpan.org/Ticket/Display.html?id=77136
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.
I'm using both CPAN::Meta::Converter and "use JSON -convert_blessed_universally", which does its own redefining of UNIVERSAL::TO_JSON. Every time my software handles a new distribution, the following warning is emitted (four times):
Subroutine UNIVERSAL::TO_JSON redefined at [path/to/]CPAN/Meta/Converter.pm line 39
I'd say using the convert_blessed_universally mode is a bad idea in general, since its effects are not localized (and indeed after replacing it with local *UNIVERSAL... all warnings are silenced), but CPAN::Meta::Converter should also silence "redefine" warnings. In this particular case, since the redefinition is local, there is no reason for a warning.
this is a breadcrumb issue for later investigation.
Handling of 'conflicts' and version ranges might be wrong. For normal
requirements, a bare version '1.0' means "accepts >= 1.0". But for conflicts,
a bare version ought to mean "doesn't accept <= 1.0". This is not exactly a
full inversion. Is some of the code wrong?
(Also, need to clarify how version ranges including commas are handled. Does
deMorgan's law apply and we interpret "1.0, 2.0" as meaning "doesn't accept
1.0 OR 2.0"?)
@kentnl's investigation code (captured from a nopaste sent during QAH, before it vanishes):
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
After installing all the modules listed by dzil authordeps
...
$ 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
dzil build
blew up with:
Your configuration file couldn't be loaded.
Can't locate Dist/Zilla/PluginBundle/RJBS.pm in @INC
The CMP constructor will accept "x_" fields, but 'with_merged_prereqs'
does not: it only takes "official" fields and it really take those, plus
any "x_" fields.
I'm not sure if I'll get to this by/for Lyon, but I'd like to create a new module in this distribution, as an appendix to CPAN::Meta::Spec, that documents known instances of x_* fields in the metaspec, what they are used for and how prevalent they are -- with the idea that some of these fields might make it into v3 -- or at least so tool authors know they exist and can build more tools around them if they look useful. It would of course be an informal document and not considered a specification, and no promise would be made regarding the future blessing of any such fields.
It would be useful to have a standard way in metadata to specify positive or negative OS requirements.
re #toolchain 2013-07-10/11:
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
I would like to consume the copyright year from the meta file, real life use case: https://metacpan.org/source/DAM/DhMakePerl-0.79/lib/DhMakePerl/Command/Packaging.pm#L983
Authoring systems like Dist::Zilla or Module::Starter already provide the year, but currently only for purposes of rendering documentation boiler-plate from which it's difficult to extract. Therefore in order to stream-line automated packaging I propose to amend the spec with the copyright year.
I know there's probably no useful application for merging conflicts and requirements together, but all the same, I believe one of the following should apply:
use strict;
use warnings;
use utf8;
use Test::More;
use CPAN::Meta::Prereqs;
my $reqs = CPAN::Meta::Prereqs->new(
{
runtime => {
conflicts => { 'Foo' => '== 1.5' },
requires => { 'Foo' => '> 1.0' },
recommends => { 'Foo' => '> 1.1' },
suggests => { 'Foo' => '> 1.6' },
},
},
);
note explain $reqs->merged_requirements( ['runtime'], [ 'conflicts', 'requires', 'recommends' ] )->as_string_hash;
eval { # barfs
note explain $reqs->merged_requirements( ['runtime'], [ 'conflicts', 'requires', 'recommends', 'suggests' ] )->as_string_hash;
};
Here in the first example, the fusion of conflicts and requires produces a rather useless
{
'Foo' => '== 1.5'
}
Where I think the more useful result would be
{
'Foo' => '> 1.1, !=1.5'
}
Similarly, the second result presently barfs, but mostly due to its assumption that > 1.6
and == 1.5
can't both be satisfied.
Where the merge could simply be represented as
{
'Foo' => '> 1.6'
}
Similarly, simply by re-writing the conflicts code into the inverse requirements code gives a valid merge for both
use strict;
use warnings;
use utf8;
use Test::More;
use CPAN::Meta::Prereqs;
my $reqs = CPAN::Meta::Prereqs->new(
{
runtime => {
requires => { 'Foo' => '> 1.0, !=1.5' },
recommends => { 'Foo' => '> 1.1' },
suggests => { 'Foo' => '> 1.6' },
},
},
);
note explain $reqs->merged_requirements( ['runtime'], [ 'conflicts', 'requires', 'recommends' ] )->as_string_hash;
note explain $reqs->merged_requirements( ['runtime'], [ 'conflicts', 'requires', 'recommends', 'suggests' ] )->as_string_hash;
And the output is as I might expect:
{
'Foo' => '> 1.1, != 1.5'
}
{
'Foo' => '> 1.6'
}
perl-5.18.1 RHEL6
CPAN-Meta-2.132140.tar.gz
Parse-CPAN-Meta-1.4405.tar.gz
utf8 "\xE9" does not map to Unicode at /opt/work/cis.perl.build/lib/Parse/CPAN/Meta.pm line 90, <$fh> chunk 1.
It's not quite clear from the spec how 'provides' and 'no_index' are parsed if both are used.
https://rt.cpan.org/Ticket/Display.html?id=84611
With the exception of 'resources', the 1.X specs don't say anything about custom keys. We have interpreted it liberally, so that custom keys are allowed (and upconverted to x_$name in v2).
This may be inconsistent with other validators and some authors want a stricter option.
The Validator and Converter classes should take an option for a stricter mode. Validation would not allow custom keys (outside 'resources' as defined) and conversion would delete custom keys.
We've historically avoided XS because of reliability issues. However, for speed, we could consider optimistically trying XS serializers and falling back to PP if they aren't installed or return an error. That would mean two runs for every error, but much faster performance for the more typical error-free case for those who have them installed.
We could recommend XS modules if we trusted them to be stable and sane over time.
Currently, the validator defines a number of meta attributes as lazylists: author, license, keywords, resources.license. These will accept both an array of strings or a string as a value. This is contrary to my reading of the spec, which says they should be a List of one or more Strings. So I think that either
It should be noted that none of ExtUtils::MakeMaker, CPAN::Meta::Convert, Module::Build or Dist::Zilla seem to generate meta structures with strings instead of arrays, so I suspect it could be strictened without too much hassle.
this might be an issue of CPAN-Meta-Requirements, but here we go:
"make test" of CPAN-Meta-2.142690 is ok with CPAN-Meta-Requirements-2.129, and fails with CPAN-Meta-Requirements-2.130, output from "make test" with C-M-R-2.130:
t/strings.t .............. 1/? Undefined requirement for Foo::Bar treated as '0' at t/strings.t line 59
t/strings.t .............. Dubious, test returned 1 (wstat 256, 0x100)
Parse::CPAN::Meta is pretty tightly coupled. Now that both distributions are core, there's little benefit to keeping them separate. PCM should get merged into CPAN-Meta.
I make no pretence that this is the solution to anything. I just though I'd make a note of what I have stumbled across.
Tracing thru Module::Build V 0.4204 and CPAN::Meta V 2.120921 I found I could stop the auto-deletion of META.* by this patch to CPAN::Meta::Validator:
Insert new line 736 (since I'm using license => 'artistic_2' in Build.PL):
$value =~ 'artistic_2' if ($value eq 'artistic_2_0');
An alternate fix would be to expand the my %v2_licenses declaration just above to include artistic_2_0. I have no idea what the ramifications of this would be.
According to this RT ticket, in sounds like invalid version numbers in the META are truncated or turned into 0 by default.
I thought the whole idea of the META spec was to have a formal interface for describing a distribution. Futzing with version numbers seems contrary to that.
Can you help my understand why this change was made?
https://rt.cpan.org/Ticket/Display.html?id=67189
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".
Provide unified way how to handle non perl dependencies, eg C libraries.
Proposal:
extend current:
requires => { package => version }
to:
requires => { 'ACME::Extra::Dependencies::PkgConfig' => [
{ mod => 'glib-2.0', min_version => '2.42.0' },
{ mod => 'gtk+3.0' },
]}
Right now, the convention is merely to add a ' (DEPRECATED)' string in the =head1 NAME
section of module pod. If there were a field in metadata, clients such as metacpan could indicate the deprecation status more clearly, use it in search results, etc.
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!" ;)
https://rt.cpan.org/Ticket/Display.html?id=83506
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?
https://metacpan.org/pod/CPAN::Meta::Spec#keywords - "Keywords must not include whitespace." However, CPAN::Meta::Validator only validates the 'keywords' entry as { list => { value => &string } }. 'string' is too lax here.
The other meta validation packages also contain the same issue: Test::CPAN::Meta::Version, Test::CPAN::Meta::YAML::Version, Test::CPAN::Meta::JSON::Version.
Here's an example in the wild that should fail a validation test: https://metacpan.org/source/TOBYINK/Type-Tiny-0.038/META.json#L8
https://rt.cpan.org/Ticket/Display.html?id=72094
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.
The CPAN client has an option halt_on_failure
, defined as "stop processing after the first failure of queued items or dependencies". It defaults to false. Regardless of its intent (which is an issue for the CPAN.pm queue, not here), when false, the outcome is that a distribution with unfulfilled dependences is still deemed to have been installed correctly.
This violates the spec (emphasis mine):
Requirements for regular use must be listed in the runtime phase. Other requirements should be listed in the earliest stage in which they are required and consumers must accumulate and satisfy requirements across phases before executing the activity. For example, build requirements must also be available during the test phase.
https://metacpan.org/module/CPAN::Meta::Spec#PREREQUISITES
My question is this: is it acceptable, as per the spec, for cpan clients to report the test and install steps of building a dist as successful despite the lack of proper fulfillment of the prerequisites? At a minimum, a documentation amendment is in order, but I'm not sure what that should say.
this was somewhat discussed today on #toolchain after the creation of https://rt.cpan.org/Ticket/Display.html?id=89389 and similar tickets.
As seen on #[email protected]
This code block involves CPAN::Meta::Merge
, and renders some painful problems, and its not clear if its a dzil bug, or a CPAN::Meta::Merge
bug or both (that is to say, its not obvious where code has to be changed for this to continue to work)
sub _build_distmeta {
my ($self) = @_;
require CPAN::Meta::Merge;
my $meta_merge = CPAN::Meta::Merge->new(default_version => 2);
my $meta = {
...
release_status => ($self->is_trial or $self->version =~ /_/)
? 'testing'
: 'stable',
...
};
for ($self->plugins_with(-MetaProvider)->flatten) {
$meta = $meta_merge->merge($meta, $_->metadata);
}
return $meta;
}
Now, you combine this block of code with a plugin that does
[Metadata]
release_status = unstable
And the side effect is as if they'd done as follows:
use CPAN::Meta::Merge;
my $meta_merge = CPAN::Meta::Merge->new(default_version => 2);
my $meta = { 'release_status' => 'stable' };
$meta = $meta_merge->merge( $meta, { 'release_status' => 'unstable' } );
# Can't merge attribute release_status
Interestingly, replacing the second value with a bogus value like "development" or "asdf" silently has no problem here
use CPAN::Meta::Merge;
my $meta_merge = CPAN::Meta::Merge->new(default_version => 2);
my $meta = { 'release_status' => 'stable' };
$meta = $meta_merge->merge( $meta, { 'release_status' => 'Beware the jabberwock my son' } );
( I suspect due to the invalid term simply getting ignored and aliased to "stable" )
use CPAN::Meta::Merge;
my $meta_merge = CPAN::Meta::Merge->new(default_version => 2);
my $meta = { 'release_status' => 'testing' };
$meta = $meta_merge->merge( $meta, { 'release_status' => 'BEWARE THE JABBERWHAT!?' } );
# Can't merge attribute release_status at
More over, the failure message it renders in such a case could be improved either way, had to do a bit of debugging to trace what was causing it =)
Can't merge attribute release_status at <some line in Dist::Zilla>
Could be more descriptive + more context.
I've been working on a new dist that stuffs a lot of data into the "optional_feature" section of the metadata. Test::CPAN::Meta complained with things like: "Key 'Module Development' is not a legal identifier. (optional_features -> Module Development)"
Deep in Test::CPAN::Meta::Version I found:
sub identifier {
my ($self,$key) = @_;
if(defined $key) {
return 1 if($key && $key =~ /^([a-z][_a-z]+)$/i); # spec 2.0 defined
...
...which indicates the legal syntax for an identifier. However, I cannot find
any mention or paraphrasing of this regexp in CPAN::Meta::Spec itself -- the
closest I can find is the definition of "string", which is "[a] data element
containing a non-zero length sequence of Unicode characters". There are a few
subtypes of Strings defined, for specific fields (such as License and URL),
but nothing pertaining to generic identifiers such as keys used in a Map.
This looks to be an oversight -- the syntax for a Map key should be explicitly
defined.
I recently had an issue with PAUSE refusing to index a version of my dmake distribution, which includes no .pm files, being a binary build of the dmake.exe build program on Windows.
A workaround solution of adding a 'provides' key to the metadata was suggested in PAUSE's issue #110 here: andk/pause#110 (comment)
That worked well, but I have now had a bug report on rt.cpan.org that this is an invalid use of 'provides' since there is no 'package dmake' in the META.yml file: https://rt.cpan.org/Ticket/Display.html?id=95273
@dagolden thought this was ok in andk/pause#110 (comment), but the spec doesn't actually say that: http://search.cpan.org/~dagolden/CPAN-Meta-2.141170/lib/CPAN/Meta/Spec.pm#provides
Please can you either update that spec to match what I've done if that really is ok, or else provide some other means of achieving my goal.
This issue is a reminder about problems experienced with #47
I'm not sure we have a good solution for this other than to go improve fragile tests in other toolchain modules.
tldr version: if dynamic_config=1, can we list more prereqs than may
eventually be added to MYMETA, or must it be a subset of the final list?
(2014-03-04, #web-simple)
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?
This is something I want to look at before Lyon, to figure out the scope of the work involved.
Ideally:
From a discussion at Lyon:
If both 'provides' and 'no_index' are present, only 'provides' is used and 'no_index' is ignored, because 'no_index' is only used in the scan of modules (for looking for namespaces), which we do not do when 'provides' is present.
This needs to be clarified, perhaps in a "notes for implementors" section.
According to the spec I can use ...a Software::License subclass name (e.g. 'Apache_2_0')...
. However, even though the Perl_5 license exists, I get the following:
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]"
]
Report prompted by CPANTS barfing on me with "license invalid". For the time being simply reverting back to perl
.
https://rt.cpan.org/Ticket/Display.html?id=86808
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
Per #40 we need a way of converting fragments as might be given by meta_merge
fields into a specific version.
Something like this:
$cmc->convert_fragment( from_version => "1.4", to_version => "2" );
This could pick off pieces of the conversion specs. We need the "from_version" unlike the "convert" method because a fragment won't necessarily have a meta-spec field. (Though we could mandate one, I suppose.)
Alternatively, this could be done via an option to "convert", in which case, we do need to mandate a meta-spec field, and the conversion needs to use spec fields that match the input fields.
missing mention of:
https://rt.cpan.org/Ticket/Display.html?id=66120
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/
All,
I attempt
$mgr = CPAN::Meta::Merge->new(default_version => "2");
$merged_meta = $mgr->merge($cpan_meta_obj1, $cpan_meta_obj2);
and get
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.
Presume that as_struct should be used @ line 172?
MAJ
https://rt.cpan.org/Ticket/Display.html?id=58385
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
https://rt.cpan.org/Ticket/Display.html?id=85051
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
https://rt.cpan.org/Ticket/Display.html?id=84538
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.
https://rt.cpan.org/Ticket/Display.html?id=82860
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
https://rt.cpan.org/Ticket/Display.html?id=84620
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 continue my fight to get more people mark their VCS in the META files:
http://blogs.perl.org/users/gabor_szabo/2013/09/licenses-and-the-repository-links-on-cpan.html but I know there are a few CPAN authors who use private VCS.
(or don't use at all, but let's not be judgemental).
It would be probably useful to be able to tell apart people who have private VCS (or for some other way do not want to share the link), from people who just don't know about the META field or have forgotten to update it.
Would it be possible to let those people somehow communicate this?
e.g. by setting the type => 'private' ?
resources => {
repository => {
type => 'private',
},
}
v2 allows a list but v1.4 only takes a string. Should it take the first valid license in the list when downgrading?
Currently CAPN::Meta does not accept a url like [email protected]:skaji/hello.git (the shorter scp-like syntax for the SSH protocol).
Please look at https://gist.github.com/shoichikaji/90e2eefd196dc2277d9b
Is it reasonable for CPAN::Meta to accept such urls?
(I'm using Minilla, and it tries to set such url to CPAN::Meta. So it does not work. If CPAN::Meta does not accept such url, I'm going to raise a issue to Minilla.)
Modules in 'provides' are used (as the candidates) for indexing. We want to add a new boolean field under {provides}->{$module_name}
that indicates "do not index this; information included for other purposes only" (e.g. the new concept of "permissions", being discussed)
https://rt.cpan.org/Ticket/Display.html?id=79830
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.