Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Dist-Zilla CPAN distribution.

Report information
The Basics
Id: 75462
Status: resolved
Priority: 0/
Queue: Dist-Zilla

Owner: Nobody in particular
Requestors: kwilliams [...]

Bug Information
Severity: Normal
Broken in: 4.300009
Fixed in: (no value)

Subject: Some stuff doesn't work with non-standard layouts
So - someone submitted a doc-typo-patch to me yesterday for a module I haven't updated in several years (since 2005, really). The first thing I did was convert from CVS to Git & stick it on GitHub: . The second thing I did was convert from Module::Release to Dist::Zilla. But I notice a couple of things not working, which I think must be related to not using a lib/ directory. I've got one top-level .pm file, and one XS module that lives in its own subdirectory, Instance/ . When I configure my 'dist.ini' with both [PkgVersion] and [PodVersion], I don't get my $VERSION updated in either my code or POD. When run in the debugger (perl -d `which dzil` build), I see that the `$self->found_files` call in Dist::Zilla::Plugin::PkgVersion::munge_files() is returning an empty arrayref. Not sure where to take it from here. Also, I do feel something of a Karmic Blowback, since when I started writing Module::Build I decided the Standard Way of organizing a distribution ought to be in a lib/ directory. =)
I think in this case I'm going to work around it by just moving the .pm to lib/ .
Download (untitled) / with headers
text/plain 655b
The other solution would be to replace one of the :ColonPrefixNamed file finders. Probably InstallModules or something. Tell it to find files ending in .pm in the dist root, not just things in lib. But I'm guessing you'll then start finding stuff that assumes that the filename matches the package name – though I could be wrong. From early on, I said that I wouldn't take special effort to prevent ./ instead of ./lib/Foo/, but that I wouldn't bother trying to support it, either. So, it's very much "patches welcome." It'd be nice to know it works, but for me, it's always easier to put things in ./lib. Good luck! -- rjbs

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to