I can't see how that would be the case. At least I've never encountered it. I agree that some implementations can make some things difficult or impossible: you can't read the Pod in a module using perldoc if dzil hasn't built the distro, for example (I don't use Pod::Weaver's "magical" features for that reason). However, I have never encountered a situation where writing or running tests was affected. The tests should be able to use the library irrespective of the condition of Pod or the inclusion of dzil-specific directives. While you can run tests with dzil test you can equally just use prove.
I am not sure whether Dist::Zilla runs or passes its tests on Windows. I would say it's quite rare in general for a CPAN author to develop on Windows, and the fact of the matter is that Dist::Zilla has become the de facto standard for releasing to CPAN. This is simply because once you spend the time to learn it, it saves you hours of time and aggravation when updating a distribution. I urge anyone who contributes original or patched content to CPAN to bite the bullet and spend half a day getting up to speed. You'll be glad you did!
The way forward always starts with a minimal test.
| [reply]
[d/l]
[select] |
I've experienced this problem Corion is talking about, a released version of one of the many plugins was failing, and borked the installation process. Had to dig reasonably deep then install a development version of the plugin from github to get d::z to even install.
| [reply] |
Even if it is rare for a Perl developer to develop under Windows, that statistic doesn't help me. I develop 90% of my CPAN modules on Windows, so Dist::Zilla not working or not intending to support Windows directly rules it out for me.
| [reply] |
Hi Corion, for the record, "Dist::Zilla not working or not intending to support Windows" is not the case. I checked and found that at least one CPAN author of two or three dozen modules is using Windows and Dist::Zilla: Mithaldu, aka Christian Walde, who told me:
"The main advice I can give is: before releasing to cpan, grab the previous tarball, unpack it, put it in a git repo, add all, delete everything, make a build, unpack that into the git repo, and git diff. Reason being: sometimes you end up with tools applying OS newlines, which means the entire file changes if it was released on linux previously.
Also, some of the less attentively coded 3rd-party plugins (some of the git stuff) can refuse to test/work on windows.
dzil itself had some rough patches on certain systems due to not being aware of asynch file deletion on windows, but all of those things should be fixed via 1 second sleep loops now.
Also I note that, while v.5x appears to have had some Win32 test failures, the current distribution has 100% passing on Win32.
The way forward always starts with a minimal test.
| [reply]
[d/l] |
I am not sure whether Dist::Zilla runs or passes its tests on Windows. I would say it's quite rare in general for a CPAN author to develop on Windows, and the fact of the matter is that Dist::Zilla has become the de facto standard for releasing to CPAN.
10% adoption sandard? Heh. Its popular so it has to be good :p Doesnt even have to be backwards compatible
| [reply] |
