rjbs / dist-zilla Goto Github PK
View Code? Open in Web Editor NEWscary tools for building CPAN distributions
Home Page: http://dzil.org/
scary tools for building CPAN distributions
Home Page: http://dzil.org/
See Dist::Zilla::Plugin::MakeMaker::Awesome -- META.json contains:
"author" : "\u00c3\u0086var Arnfj\u00c3\u00b6r\u00c3\u00b0 Bjarmason [email protected]"
: [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.
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"
}
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(陶敏修)]:
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 ...................... okTest 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?
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.
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.
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.
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.
[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).
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)
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
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).
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 is about the plugin Dist::Zilla::Plugin::NextRelease
.
I posted the issue also at the Changes Spec developers site, detailed description is there:
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?
dzil help run
shows this:
dzil run [ run command [ arg1 arg2 ... ] ]
There is no real documentation, and why are there two run
s in the usage line? And why are all arguments optional?
Can one specify certain modules as required for tests only?
shell$ cat >> dist.ini
[TestRequires]
Test::Most = 0
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 :)
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. :-)
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.
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).
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. :-(
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.
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
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.
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.
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
.
dzil help nop
is empty.
dzil help setup
is also empty.
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
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?
dzil help help
shows its usage as
dzil help
That should be something like
dzil help [command-name]
because help can take an argument.
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.
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"
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 )
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.
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?
[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?
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.
=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?)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)content
fatalInMemory
and FromCode
) will need to generate them correctly, priming content
with bytes or decoded_content
with text; specifically:
Dist::Zilla::_write_out_file
is probably okay, as ->content
will still be bytes (but more correct) in the futurexdg 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
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
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
)?
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.
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.
This would be use option to use a specific CPAN client whenever calling dzil install
.
It's possible to get through a 'dzil build' without various prereqs being 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.
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
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
.
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
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
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) ;)
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.