Dist::Zilla was hastily cobbled together, and nowhere does that show more than in its poor support for characters outside of ASCII. It has no real concept of encoding/decoding boundaries. Worse still, many of these boundaries would need to be enforced not by Dist::Zilla, but by in external libraries written to support it.

Inputs to Fix

• Mixin::Linewise is used to read both Pod and configuration; it should be reading text, not bytes; rjbs/Mixin-Linewise#3
• Pod::Eventual and Pod:Elemental are used to parse Pod; they will, in theory, be fixed by the fix for Linewise, but we will want something in place to think about =encoding
• dzil setup should properly transcode to the produced file; assuming UTF-8 at both ends is not good enough (I guess Win32 is still not UTF-8 terminal by default?)
• File objects return their content as bytes; they should keep doing so, but should also have an encoding attribute and a decoded_content method; when these are mutable, they should be kept in sync automatically and lazily (task needed)
• we can (and probably should) make wide characters in content fatal
• things that generate in-memory files (that's both InMemory and FromCode) will need to generate them correctly, priming content with bytes or decoded_content with text; specifically:
  • Software::License needs to clarify whether it returns text or bytes; (it should be text!)
  • InlineFiles needs to clarify whether it returns text or bytes; (it should be bytes!)
  • files created from templates stored in source should be checked; in most cases, right now, they are bytes; if the file uses utf8, make sure it's text, etc.
• we should make at least a cursory review of popular plugins that will get things wrong; for example, ContributorsFromGit, I think, will be sticking bytes into places that we'll be expecting strings
• abstract extraction needs to be fixed to extract text rather than bytes

Outputs to Fix

• Dist::Zilla::_write_out_file is probably okay, as ->content will still be bytes (but more correct) in the future
• STDOUT/STDERR may need encoding layers applied
• ...but the Test chrome should be capturing strings, if easy enough
• ...are there any more outputs?

Miscellany

• Does PPI prefer octets? Text? Or is it just broken here? Find out.

In perlpodstyle, it says:

The description should ideally fit on a single line, even if a man program replaces the dash with a few tabs

The words should ideally lead me to believe that it could be 2 lines. If it is, the plugin will fail. A very simple fix would be to change line 23:

$_++; # move past the line with the abstract

to this:

$_++ while ( $content[$_] !~ /^\s*$/ ); # move past the abstract

As this is my first module, it is just as likely that this is desired behavior but the perlpodstyle seems to leave the door open and it would be simple to support multi-line abstracts... Anyway, I modified my module to be one line but figured I would submit the bug anyway.

• x
• x

the problem arose in https://rt.cpan.org/Ticket/Display.html?id=89362

I released http://metacpan.org/module/Dist::Zilla::Plugin::CheckSelfDependency to deal with it, but this should probably be in core.

poke me when you come back here and I'll send patches (or just steal the guts of this plugin) ;)

[MetaTests] uses Test::CPAN::Meta, which only tests META.yml. We should also/instead use Test::CPAN::Meta::YAML and Test::CPAN::Meta::JSON, to test both files (depending on which are generated).

placeholder for a future patch -- or should this be handled in a new plugin?

Hi,

I just done 'cpanm Dist::Zilla', and got the error message:

Building and testing Dist-Zilla-4.300034 ... FAIL

so I ran manually 'sudo make test' in the "work" folder and find this error at the end of harness report:

...
t/plugins/uploadtocpan.t ...... ok
t/tester-demo.t ............... ok
t/tester.t .................... 1/? Can't locate object method "basename" via package "Path::Class::Dir" at /Users/nicolas/.cpanm/work/1371577578.25347/Dist-Zilla-4.300034/blib/lib/Dist/Zilla/Dist/Builder.pm line 501.

Tests were run but no plan was declared and done_testing() was not seen.

t/tester.t .................... Dubious, test returned 2 (wstat 512, 0x200)
All 3 subtests passed
t/util.t ...................... ok

Test Summary Report

t/tester.t (Wstat: 512 Tests: 3 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
Files=41, Tests=559, 139 wallclock secs ( 0.24 usr 0.15 sys + 93.71 cusr 9.72 csys = > 103.82 CPU)
Result: FAIL
Failed 1/41 test programs. 0/559 subtests failed.

Then, I have upgraded Path::Class 0.16 => 0.32 and t/tester.t is now ok.
May you can add a minimun version for this module?

Hash::Merge::Simple merges hashes, but not arrays.

Because there are many array-ref fields in CPAN::Meta::Spec, this is a problem for plugins that try to accumulate arrays.

We need something less simple than Hash::Merge::Simple.

dzil help help shows its usage as

dzil help

That should be something like

dzil help [command-name]

because help can take an argument.

As per subject. Sample fail report:

http://www.cpantesters.org/cpan/report/d8ebe4bc-2170-11e3-9b89-bac4a0a565e3

I just reproduced the result with 5.19.3.

seems like Dist::Zilla assumes everything is in byte strings.

First of all, it would be nice if everything is handled as strings internally - decoded in the input, encoded in the output. i.e. rsrchboy/Dist-Zilla-Plugin-ContributorsFromGit#4 (comment)

But i understand it's difficult at this point to upgrade all plugins to follow that, unless you have a plugin API version number etc. to force upgade - and handling them in a relaxed manner doesn't get any "correct" result (i.e. utf8::is_utf8 is wrong) - Perl has no way to tell $str is meant to be bytes or strings programatically.

Given that, if dzil assumes that author names should be in (hopefully UTF-8) byte strings, some of the META plugins needs to be updated to follow that. Right now, author names in either dist.ini or from ContributorsFromGit (without my patch in pull req 4), will make a doubly encoded META.yml and META.json.

; dist.ini
author = 宮川達彦

generated META.json

"author" : "\u00e5\u00ae\u00ae\u00e5\u00b7\u009d\u00e9\u0081\u0094\u00e5\u00bd\u00a6"

dzil commands displays dzil usage information:

dzil <command> [-Iv] [long options...]
        -v --verbose      log additional output
        -I --lib-inc      additional @INC dirs

... followed by the list of available commands.

dzil help only shows the list of available commands.

I think this is backwards.

Hi there,

I think I reported this in RT a while ago, but I can't seem to find it, so I think it may have been lost in the move to GitHub issues.

It would be nice if log warnings went to standard error. I run dzil listdeps --missing on one of my repositories and see this on standard output:

[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Link/InterWiki.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Paragraph.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Bold.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Deleted.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/ListItem.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Link/WindowsShare.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Underlined.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Heading.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/EmailAddress.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Subscript.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Link.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/NoTOC.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Link/External.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Superscript.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Role/Parser/CamelCaseLinks.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Footnote.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Italic.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Link.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Image.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Link/Internal.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/List.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Monospace.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Document.pm
[@Default/Name] couldn't find abstract in lib/Text/DokuWiki/Element/Text.pm
Test::HTML::Differences

I often do something like dzil listdeps --missing | xargs cpanm, and this really messes cpanm up.

Thanks,
Rob

dzil help nop is empty.

dzil help setup is also empty.

As of Module::Build 0.4007[1], which depends on a recent version of Pod::Man, it has a parameter option extra_manify_args , that can take a hash of parameters.

ie:

yadayayaydabuildpl(
    ...
    extra_manify_args => { 
        utf8 => 1,
    }
)

This means that the generated man pages will encode literal UTF-8 Characters, instead of translating UTF-8 characters to simply X

However, that said, this is not without warnings: https://metacpan.org/module/Pod::Man#utf8

However, be warned that *roff source with literal UTF-8 characters is not supported by many implementations and may even result in segfaults and other bad behavior.

the input encoding of your POD source must be properly declared unless it is US-ASCII or Latin-1. POD input without an =encoding command will be assumed to be in Latin-1, and if it's actually in UTF-8, the output will be double-encoded

Though given Dzil is encoding by default now, and =encoding should become progressively standard, the latter point seems to be acceptable.

And from my personal testing, I discovered that making this change changed my standard MAN page output from X to an accented â when I asked it to render → , because the roff toolchain for me is apparently not smart enough yet to identify documents with UTF8 encoding.

Though, as soon as I figured out export GROFF_ENCODING=utf8 would do what I wanted, the emitted documentation contained the right output symbols in many output formats ( terminal, pdf, dvi, html ), html even did the right thing and emitted →

And output to ascii is amazing, it turns → to "->". Nice!

GROFF_ENCODING=utf8 groffer Gentoo::Dependency::AST::State -Tascii --to-stdout | cat

So given the above, it seems productive and desirable, at least for me, to have that option turned on. Maybe it should be on by default, I don't know.

--- Build.PL    2013-10-22 14:00:41.452116199 +1300
+++ Build.PL.new    2013-10-22 14:52:29.232132667 +1300
@@ -18,6 +18,9 @@
   ],
   "dist_name" => "Gentoo-Dependency-AST",
   "dist_version" => "0.001001",
+  "extra_manify_args" => {
+    "utf8" => 1,
+  },
   "license" => "perl",
   "module_name" => "Gentoo::Dependency::AST",
   "recommends" => {},
@@ -54,6 +57,10 @@
   }
 }

+unless ( eval { Module::Build->VERSION(0.4007) } ) {
+  delete $module_build_args{extra_manify_args};
+}
+
 my $build = Module::Build->new(%module_build_args);

 $build->create_build_script;

1: The feature was added in 0.4006, but its not likely to work at that version due to 0.4006 not depending on a recent enough Pod::Man to support the option.

Hi all,

thanks for Dist-Zilla.

In the XML-Grammar-Fiction repository (see https://bitbucket.org/shlomif/fiction-xml/overview ):

I have this in my dist.ini :

[Prereqs]
MooX::late = 0.010
XML::GrammarBase::Role::XSLT = 0.2.1
-phase = test
Test::XML::Ordered = 0.0.5

And I get this in Makefile.PL :

  "TEST_REQUIRES" => {
    "Config" => 0,
    "File::Find" => 0,
    "File::Temp" => 0,
    "MooX::late" => "0.010",
    "Test::More" => 0,
    "Test::XML::Ordered" => "v0.0.5",
    "XML::GrammarBase::Role::XSLT" => "v0.2.1",
    "parent" => 0,
    "utf8" => 0
  },

Which in turn perl Makefile.PL warns that:

shlomif[xml-fiction]:$fict/XML-Grammar-Fiction-0.14.1$ perl Makefile.PL
Unparsable version 'v0.2.1' for prerequisite XML::GrammarBase::Role::XSLT at Makefile.PL line 93.
Unparsable version 'v0.0.5' for prerequisite Test::XML::Ordered at Makefile.PL line 93.
Writing Makefile for XML::Grammar::Fiction
Writing MYMETA.yml and MYMETA.json
shlomif[xml-fiction]:$fict/XML-Grammar-Fiction-0.14.1$

And this results in many test failures for unmet dependencies such as http://www.cpantesters.org/cpan/report/0a5dcb9c-b0f5-11e2-b477-b7bcc9f799f9 .

This really should be corrected. I am using:

shlomif@telaviv1:~/Download/unpack/perl/cpan/Dist-Zilla-4.300034$ perl -MDist::Zilla\ 9
Dist::Zilla version 9 required--this is only version 4.300034.
BEGIN failed--compilation aborted.

Best regards,

— Shlomi Fish

dzil help run shows this:

dzil run [ run command [ arg1 arg2 ... ] ]

There is no real documentation, and why are there two runs in the usage line? And why are all arguments optional?

I entered dzil new and got this usage message:

Error: dzil new takes exactly one argument
Usage: dzil <command> [-Iv] [long options...]
        -v --verbose      log additional output
        -I --lib-inc      additional @INC dirs

dzil [-Pp] [long options...] <ModuleName>
        -p --profile      name of the profile to use
        -P --provider     name of the profile provider to use

So, following the first form that it suggested, I tried dzil new -v DateTime::Moonpig, and got the same usage message. It seems that contrary to the usage message's advice, the -v flag is illegal with new.

It would be lovely if dzil had a --version style option that reported which version of Dist::Zilla is being used.

Please feel free to tell me not to use git's issue-tracker for lightweight wishlist items. ;)

Paul

dzil setup asks What license will you use by default (Perl_5, BSD, etc.)? [Perl_5]:. I wanted to put public domain, but there's no clear way to do that. I tried typing ?, hoping for a list of acceptable options, but that just said Invalid selection, please try again.

Can one specify certain modules as required for tests only?

shell$ cat >> dist.ini

[TestRequires]

Test::Most = 0

dzil commands is redundant because dzil help also shows the list of available commands.

dzil commands foo isn't equivalent to dzil help foo but it doesn't error out either; it just ignores foo.

Why does commands need to exist as a separate command?

This test blows up with "Required plugin [=inc::MyMetadata] isn't installed...."

use strict;
use warnings FATAL => 'all';

use Test::More;
use Dist::Zilla::Tester;
use Test::DZil;

my $tzil = Builder->from_config(
  { dist_root => 't/empty_dir' },
  {
    add_files => {
      'source/dist.ini' => simple_ini(
        [ GatherDir => ],
        [ MetaJSON => ],
        [ '=inc::MyMetadata' ],
      ),
      'source/inc/MyMetadata.pm' => <<PLUGIN
package inc::MyMetadata;
use Moose;
with 'Dist::Zilla::Role::MetaProvider';
sub metadata { {} }
1;
PLUGIN
    },
  },
);

$tzil->build;

Creating a similar corpus directory in the filesystem and running 'dzil build' on it works -- does the test builder not know how to support =inc plugins? I'm tracing through the code and nothing jumps out as suspicious.

In dzil setup, if you decide to set up PAUSE account information, the password typing is not masked. IMO it has to be masked.

There's some comment in the dzil script that sets $VERSION using $Dist::Zilla::VERSION - but it's funny that dzil --version isn't implemented.

It'd be nice if we have it implemented :)

PERL5OPT="-MCarp::Always" dzil build
[DZ] beginning to build Gentoo-Dependency-AST
[DZ] guessing dist's main_module is lib/Gentoo/Dependency/AST.pm
Wide character in subroutine entry at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Role/PPI.pm line 40.
    Dist::Zilla::Role::PPI::save_ppi_document_to_file(Dist::Zilla::Plugin::PkgVersion=HASH(0x4254a20), PPI::Document=HASH(0x5f97c90), Dist::Zilla::File::OnDisk=HASH(0x3457e80)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Plugin/PkgVersion.pm line 103
    Dist::Zilla::Plugin::PkgVersion::munge_perl(Dist::Zilla::Plugin::PkgVersion=HASH(0x4254a20), Dist::Zilla::File::OnDisk=HASH(0x3457e80)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Plugin/PkgVersion.pm line 34
    Dist::Zilla::Plugin::PkgVersion::munge_file(Dist::Zilla::Plugin::PkgVersion=HASH(0x4254a20), Dist::Zilla::File::OnDisk=HASH(0x3457e80)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Plugin/PkgVersion.pm line 24
    Dist::Zilla::Plugin::PkgVersion::munge_files(Dist::Zilla::Plugin::PkgVersion=HASH(0x4254a20)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Dist/Builder.pm line 269
    Dist::Zilla::Dist::Builder::build_in(Dist::Zilla::Dist::Builder=HASH(0x331f268), undef) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Dist/Builder.pm line 315
    Dist::Zilla::Dist::Builder::ensure_built_in(Dist::Zilla::Dist::Builder=HASH(0x331f268)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Dist/Builder.pm line 305
    Dist::Zilla::Dist::Builder::ensure_built(Dist::Zilla::Dist::Builder=HASH(0x331f268)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/Dist/Builder.pm line 342
    Dist::Zilla::Dist::Builder::build_archive(Dist::Zilla::Dist::Builder=HASH(0x331f268)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/Dist/Zilla/App/Command/build.pm line 30
    Dist::Zilla::App::Command::build::execute(Dist::Zilla::App::Command::build=HASH(0x28450b8), Getopt::Long::Descriptive::Opts::__OPT__::2=HASH(0x26f75e0), ARRAY(0x116ac20)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/App/Cmd.pm line 282
    App::Cmd::execute_command(Dist::Zilla::App=HASH(0x1685a38), Dist::Zilla::App::Command::build=HASH(0x28450b8), Getopt::Long::Descriptive::Opts::__OPT__::2=HASH(0x26f75e0)) called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/lib/site_perl/5.19.3/App/Cmd.pm line 210
    App::Cmd::run("Dist::Zilla::App") called at /home/kent/perl5/perlbrew/perls/perl-5.19.3/bin/dzil line 15

Have all the latest versions of things as described in http://rjbs.manxome.org/rubric/entry/2021

Granted I'm just building with my existing config that worked on dzil <5.

If its required that everyone use [Encoding] explicitly now, I don't know, I didn't see anything about that in the changes.

Just the wording is very non-threatening, it says "this plugin exists to allow", it doesn't suggest this plugin may be mandatory for proper functioning.

SRC tree is https://github.com/kentfredric/Gentoo-Dependency-AST if you want to test it.

The first question from dzil setup was What's your name?. I entered Mark Dominus (陶敏修). This appeared to work, until two questions later, when dzil setup said:

Wide character in print at /usr/local/lib/perl5/5.12.3/Term/ReadLine.pm line 193, <FIN> line 2.
Who, by default, holds the copyright on your code?  [Mark Domin(陶敏修)]: 

This is about the plugin Dist::Zilla::Plugin::NextRelease.
I posted the issue also at the Changes Spec developers site, detailed description is there:

metacpan/CPAN-Changes#17

The default format should at least fulfil the spec (or the other way round).
The spec guy proposes ISO8601.

Are there any strong opinions about this?

Loving Dist::Zilla so far, but I've hit a critical blocker. I'm sure it's me just not reading the right docs, but is there any workaround I can use to get my generated Makefile.PL to assert the correct minimum version of Perl?

In my dist.ini, I have the following:

[Prereqs]
perl = 5.010

That wrote the following in my Makefile.PL:

"PREREQ_PM" => {
      "Perl" => "5.010"
 },

That led to the following bug report: https://rt.cpan.org/Public/Bug/Display.html?id=83563

In short, perldoc ExtUtils::MakeMaker says this is how you assert the minimum Perl version:

MIN_PERL_VERSION
The minimum required version of Perl for this distribution.

Either 5.006001 or 5.6.1 format is acceptable.

So far all workarounds I've tried have failed, including using MinimumPerl, which swears that I need Perl 5.12.0, even though perlver --blame on all files reveals 5.10.0 to be the highest version needed.

I would like to avoid AutoPrereqs yet because it's missed some prereqs at work (I cannot replicate the use case).

Cheers,
Ovid

It's possible to get through a 'dzil build' without various prereqs being satisfied.

• when we perl Makefile.PL; make / perl Build.PL; ./Build, configure, build and runtime prereqs must all be satisfied.

..and then in the test phase, test prereqs must also be satisfied.

https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec

It probably makes sense to also check for 'develop' prereqs in here too.

I expect you'll want to see this in a standalone plugin first (or forever?), which is doable by composing the BuildRunner and TestRunner roles, except that run_in_build (in Dist::Zilla::Dist::Builder) only uses the first BuildRunner plugin -- which means we'll have to order this plugin to run after MakeMaker::Runner & friends. I guess that's not horrible, but it would be nice to fail earlier.

xenoterracide/Dist-Zilla-Plugin-Test-PodSpelling#17

It looks like there's a lot of different words that need to be added into the  stopwords list on this distro I'm looking at. However, the "one word per line" rule junks up the dist.ini. It would be nice if stopwords would also run through a split /\s+/ through the array to allow you to put in multiple words on one line.  

realistically I'm thinking this isn't so much a PodSpelling bug as just something that Dist::Zilla should do (assuming it doesn't now and I've just done something wrong in my code to make it do this )

This would be use option to use a specific CPAN client whenever calling dzil install.

tl;dr - i want to override $zilla->authors with the value scanned from POD documents (or git info whatever), and there doesn't seem to be a way.

If author = line exists in dist.ini, everything is well. We can forget about this situation.

When author = doesn't exist, $zilla->authors try to pick up from [%User] stash in the ~/.dzil/config.ini, which would give a different value per releaser.

I tried to delete the [%User] line from config.ini, then dzil tries to get the default author from copyright_holder, and to create a copyright holder, it has to pass the default author(!), and it returns an error:

[DZ] No %User stash and no copyright holder; can't determine dist author; configure author or a %User section

UPDATE it might be totally unrelated, since the actual error says it can't find main_module - otherwise it could totally find:

[DZ] Unable to find main_module in the distribution
[DZ] We tried to guess 'lib/Dist/Zilla/Plugin/LicenseFromModule.pm' but no file like that existed
[DZ] Upon further inspection we didn't find any files in your dist, did you add any?
[DZ] Cannot continue without a main_module
[DZ] No %User stash and no copyright holder; can't determine dist author; configure author or a %User section

I hoped that a LicenseProvider plugin could return the holder as the value to override, but $self->zilla->authors is a read-only attribute. Also, calling $self->zilla->authors inside provide_license gets a deep recursion.

Seems like I'm in the dead end, need to override authors with a hack, or remove [%User] from the stash unless it's new/add action.

Any thoughts?

xdg knows more about this; I believe he was fixing it in CPAN.pm.

09:52 <@ether> I am seeing a failure for CPAN.pm to properly resolve dependencies - is this what xdg sent in a patch for last week?  e.g. http://cpantesters.org/cpan/report/9120faf6-3a56-11e3-8a37-e2882d12fa71
09:52 <+dipsy> [ CPAN Testers Reports: Report for Dist-Zilla-Plugin-Chrome-ExtraPrompt-0.002 ] 
09:52 <@ether> File::Spec is specified at 0 in develop-requires but 3.40 in runtime-requires
09:53 <@ether> or possibly CPAN.pm says "File::Spec::Functions is satisfied at 0; I won't bother satisfying File::Spec at 3.40 because it's from the same dist"??
09:54 < ribasushi> ether: it boils down to: dzil needs to make sure that no requires are lower than runtime-requires if there are any duplicates
09:55 <@ether> I'm seeing the same thing via cpanplus as well - http://cpantesters.org/cpan/report/b13d6532-39ec-11e3-b8b2-96b61dda783b
09:55 <+dipsy> [ CPAN Testers Reports: Report for Dist-Zilla-Plugin-Chrome-ExtraPrompt-0.002 ] 
09:55 < ribasushi> ether: pretty much all CPAN.pm's are affected so even if a fix ships, the dzil fix needs to go in since the upgrade cycle for CPAN.pm is v. slow
09:55 <@ether> this is not good :(
09:56 <@ether> this should probably go into dzil core - it will take forever for everyone to apply a plugin to all their dists

kentnl wrote a plugin for this, but this is a big enough issue that IMO it
should be handled by dzil's core prereq handling.

https://metacpan.org/module/Dist::Zilla::Plugin::Prereqs::SyncVersions

@dagolden @kentfredric

dzil release --help doesn't display help for the release command. It doesn't complain about an invalid option either. It ignores the option and blindly tries to release the module. :-(

It's not really our job to ensure a working INSTALL_BASE on EU::MM. To me that seems the job of local::lib or perlbrew or plenv or whatever other tool actually depends on it.

If we drop eumm_version to 6.17, then we let modules install all the way back to v5.8.1 without forcing an EU:MM upgrade that they probably don't need (even if it would be a good idea for them to toolchain anyway).

Related to #203 -- log_fatal messages use the customized name, rather than the actual plugin name.

Probably it should use both, a la [Plugin / Name], for more easy identification of the problem dist.ini entry.

I just had a failed 'dzil release' operation, due to test failures:

: [ether@bourbon git/Moose]$; ls -alt .build
total 16
drwxr-xr-x   5 ether  staff   238 Jul 26 10:25 .
drwxr-xr-x  15 ether  staff   952 Jul 26 10:25 ..
drwx------   3 ether  staff   102 Jul 26 10:25 tTPD7cokLY
drwxr-xr-x  14 ether  staff  1156 Jul 26 10:21 LOOpVCoXTP
lrwxr-xr-x   1 ether  staff    10 Jul 26 10:20 latest -> LOOpVCoXTP
drwxr-xr-x  14 ether  staff  1156 Jul 26 10:17 0H_VV_hwC1
lrwxr-xr-x   1 ether  staff    10 Jul 26 10:16 previous -> 0H_VV_hwC1

The 'latest' symlink did not get updated to this build.
(interestingly, also, the permissions are different.)

It looks like the code path in Dist::Zilla::Dist::Builder is quite different for the 'release' command, but I got lost in the spiderweb and couldn't tell precisely what bits are missing/wrong.

See e.g. dzil help add:

dzil [-Pp] [long options...] <ModuleName>

        -p --profile      name of the profile to use
        -P --provider     name of the profile provider to use

It doesn't say where to put the names of the profile or the provider.

Similarly, dzil help build:

dzil build [long options...]

        --trial    build a trial release that PAUSE will not index
        --tgz      build a tarball (default behavior)
        --in       the directory in which to build the distribution

Presumably --in takes an argument and the other two options don't but that's not clear from the listing.

[this is a summary of my ramble on irc today, with the cruft snipped]

AutoPrereqs is currently scanning every file its finders return, using some filename heuristics to try to find package names (e.g. it assumes something special about t/lib, lib/, and back-constructs .pm files to package names).

1. this is wasted effort, as other plugins are better equipped to provide the canonical list of "packages defined by this dist" (e.g. MetaProvides, as well as possibly the core itself)

2. these heuristics aren't perfect, but if there is going to be guesswork, it would better to keep it in one place so at least the logic is the same across all usages

3. the list is not saved across multiple instances of the plugin - so for example, this configuration will provide an inaccurate list of prereqs:

   [AutoPrereqs]
   ; standard defaults

   [AutoPrereqs / psgi]
   finder = PSGI

...if the second run of AutoPrereqs finds reference to a package that is locally defined, it will be added to the prereq list because its .pm file was not scanned this time around and therefore recorded in the list of @modules that are local.

Therefore I propose that AutoPrereqs should get a little dumber, and simply report all the prereqs that it thinks it sees, whether or not there are duplicates across phases, or whether the module is available in the local dist. The core itself should be responsible for filtering out all locally-defined package names from the prereq list, when it comes time to spit those back out for whatever plugins want the list, which would require an installed plugin to implement the Dist::Zilla::Role::MetaProvider::Provider role (which I notice isn't in core).

Dist::Zilla::Plugin::NextRelease says about format:

sprintf-like string used to compute the next value of {{$NEXT}}; defaults to %-9v %{yyyy-MM-dd HH:mm:ss VVVV}d

The %-9v part is not documented. Apparently it works like %-9s in sprintf but this isn't mentioned anywhere. Does specifying the - flag and a field width work with all format codes? Does it behave as for sprintf %s in all of them? What other formatting flags/parameters are supported? How does this syntax interact with e.g. %{-TRIAL}V (is it %123{foo}V or %{foo}123V)?

In my dist.ini:

[OptionalFeature / JSON-Runtime]
...

The error:

Required plugin [JSON-Runtime] isn't installed.

Run 'dzil authordeps' to see a list of all required plugins.
You can pipe the list to your CPAN client to install or update them:

    dzil authordeps | cpanm

can patch, will travel.

Seems GPL_3 mappend to open_source (that works in M:B)
https://rt.cpan.org/Public/Bug/Display.html?id=67096

but maps to "gpl" in latest Distzilla in META.yml

$ cat dist.ini 
name=My-App
version=1.0
license = GPL_3
copyright_holder = E. Xavier Ample <[email protected]>

[@Basic]
[MetaJSON]

$ cat META.yml 

---
abstract: 'turns baubles into trinkets'
author:
  - 'E. Xavier Ample <[email protected]>'
build_requires: {}
configure_requires:
  ExtUtils::MakeMaker: 6.30
dynamic_config: 0
generated_by: 'Dist::Zilla version 4.300034, CPAN::Meta::Converter version 2.131560'
license: gpl
meta-spec:
  url: http://module-build.sourceforge.net/META-spec-v1.4.html
  version: 1.4
name: My-App
version: 1.0

{
   "abstract" : "turns baubles into trinkets",
   "author" : [
      "E. Xavier Ample <[email protected]>"
   ],
   "dynamic_config" : 0,
   "generated_by" : "Dist::Zilla version 4.300034, CPAN::Meta::Converter version 2.131560",
   "license" : [
      "gpl_3"
   ],
   "meta-spec" : {
      "url" : "http://search.cpan.org/perldoc?CPAN::Meta::Spec",
      "version" : "2"
   },
   "name" : "My-App",
   "prereqs" : {
      "configure" : {
         "requires" : {
            "ExtUtils::MakeMaker" : "6.30"
         }
      }
   },
   "release_status" : "stable",
   "version" : "1.0"
}

According to the documentation for the namespaces attribute in MetaNoIndex:

NOTE: This will not exclude the package My::Package, only everything under it like My::Package::Foo.

However, My::Package is in fact excluded with the following configuration:

[MetaProvides::Package]
inherit_version = 1
meta_noindex    = 1

[MetaNoIndex]
namespaces = My::Package

This is part of the omnibus encoding issue.. I'm having difficulty munging a file to contain unicode.

reference - https://rt.cpan.org/Ticket/Display.html?id=88016

I am looking at listdeps --missing. Is it possible that in case a prereq is already loaded (by some other plugin) that listdeps --missing thinks it's not installed?

See Dist::Zilla::Plugin::MakeMaker::Awesome -- META.json contains:

"author" : "\u00c3\u0086var Arnfj\u00c3\u00b6r\u00c3\u00b0 Bjarmason [email protected]"

I was dismayed to see my PAUSE credentials recorded in config.ini. It's probably pointless to encrypt them, but I do think that the dzil setup prompt should say that that's what's going to happen to them.

Right now all it says is

Do you want to enter your PAUSE account details?  

It should mention that they will be saved in cleartext.

IF YOU ARE NOT @rjbs or @dagolden STAY OFF THIS TICKET

• add encoding support to File
• -- make GatherDir DTRT with encoding
• add encoding to terminal chrome
• add encoding to config reader
• add encoding to Pod munging
• add encoding to other misc. sources of input
• -- Data::Section
• add encoding to other misc. output
• test PPI + encoding for potential insanity

: [ether@tequila git/MooseX-Storage].7$; dzil authordeps
Smartmatch is experimental at /Users/ether/.perlbrew/libs/19.2@std/lib/perl5/Dist/Zilla/App/Command/podpreview.pm line 50.
Dist::Zilla::Plugin::OptionalFeature
Dist::Zilla::Plugin::Prereqs
Dist::Zilla::Plugin::Prereqs/
Dist::Zilla::PluginBundle::Author::ETHER
: [ether@tequila git/MooseX-Storage].7$; dzil authordeps --missing
Smartmatch is experimental at /Users/ether/.perlbrew/libs/19.2@std/lib/perl5/Dist/Zilla/App/Command/podpreview.pm line 50.
`Dist::Zilla::Plugin::Prereqs/' is not a module name
: [ether@tequila git/MooseX-Storage].7$; grep 'Prereqs/' dist.ini
[Prereqs/ TestRequires]

I'll probably patch later; just filing this now before I forgt.

This happens partially for AutoPrereqs (though not for internal packages), but other plugins can add them. (I saw this in File::Temp when Test::Compile added File::Temp as a dependency.)

The proper behavior would be to use Module::Metadata to get all packages shipped with the distribution and then ensure they are all filtered out of prerequisite lists.

I think this is probably low priority, but better to have the issues recorded than not. :-)