Specify command-line spell checker. about file-chmod HOT 10 CLOSED

even if I specified that, there'd be no guarantee what dictionaries you have installed... I suppose I could, though I also question the sanity of the no longer maintained (IIRC) and hard to find (AFAIK) spell command being the default. I suspsect Test::PodSpelling should use that only as a last resort.

from file-chmod.

In considering this small matter, I got pretty irritated over the state of
the CPAN/Github/dzil mess, and how hard it makes it for contributors to
offer a quick fix to a bug they've run into. Dist::Zilla makes it easy for
individual maintainers to customize their workflow, but the resulting
diversity of approach means more pain when trying to collaborate with
strangers. Absent a big-picture solution, I suggest that you view
specifying a spell checker as explicitly stating a dependency of your build
system.

Unfortunately, I just ran a test and learned that if Test::Spelling can't
find the specified spell checker, it just skips the test. There should be
a way to make that a failed test so the dependency can be met or
deliberately overridden.

On Sun, Dec 15, 2013 at 10:35 PM, Caleb Cushing [email protected]:

even if I specified that, there'd be no guarantee what dictionaries you
have installed... I suppose I could, though I also question the sanity of
the no longer maintained (IIRC) and hard to find (AFAIK) spell command
being the default. I suspsect Test::PodSpelling should use that only as a
last resort.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-30631809
.

from file-chmod.

normally I offer a "build" branch for casual contributors, though I'm undecided as to whether to keep doing this. I run into a frustrated state of affairs where it confuses people. They can't seem to figure out when I set build/master to the default branch that they aren't on master, (which isn't that relevant) and then proceed to patch generated content such as the Makefile.PL. I'm undecided as to the correct approach because of this. build/master otherwise works fine for the casual contributor. Can't guarantee that they'll read the CONTRIBUTING file either. The question seems to be one of, how can I get the highest quality patches, with the least amount of effort on my part. I suppose I'll just go back to pushing the build branch, and then being a dick when people don't read the CONTRIBUTING file

from file-chmod.

I got pretty irritated over the state of the CPAN/Github/dzil mess, and how hard it makes it for contributors to offer a quick fix to a bug they've run into

Can you clarify this? In most distributions, it's still quite possible to run tests with prove -lr t and not have to perform a dzil build operation at all.

If it's not possible to run tests in this fashion, the dist should provide a file (such as CONTRIBUTING) explaining how collaborators can contribute -- but xenoterracide provides such a file in his dists, so I don't understand the problem. Can you clarify, so we can work on making the process more clear to outside contributors?

from file-chmod.

also if my CONTRIBUTING file can be improved in any way...

from file-chmod.

@xenoterracide this is what I use: https://github.com/karenetheridge/Dist-Zilla-PluginBundle-Author-ETHER/blob/master/share/CONTRIBUTING

from file-chmod.

@karenetheridge,

My complaint is that our tools make collaboration more difficult than they
might. Git and Dist::Zilla have an impedance mismatch. Git is completely
about maintaining a faithful representation of the state of your software
project as a project, not as a product. Dist::Zilla, on the other hand, is
a tool created to automate the most tedious and error-prone steps of turning
your project into a product--a CPAN distribution.

It falls to programmers to make the two work together, and that's a process
that, AFAIK, is 1) completely unstandardized, 2) communication- and possibly
compromise-intensive, and 3) just getting started. When I made my first
contribution to File::chmod, a month or so ago, there was no CONTRIBUTING
file, and I had no idea how Dist::Zilla worked. My changes failed some author
tests that I didn't even know existed. Caleb accepted my changes anyway, and
added both the CONTRIBUTING file and 'build' branches. But he himself says
(see up a few comments) that those don't fix the confusion.

Dist::Zilla compounds the problem by offering so damn many different ways of
doing things. Working on somebody else's distribution might or might not mean
reading their dist.ini, figuring out what a bunch of unfamiliar plugins do,
then tailoring your changes to work with them.

What can you or anybody do about it? Not much, I suspect. But, I can tell
you as a newcomer to the Perl community that needing to know about CPAN, git,
Github, Dist::Zilla, Pod::Weaver, and perlcritic--just to submit a
three-character patch and a 20-line test--seems like a lot of hurdles.

from file-chmod.

I don't think git and Dist::Zilla have an impedance mismatch, I think they work quite easily together. Even if there were a standardized approach (@git sort of means there is) then you add knowing about it. Mostly the complaints about dzil seem to be centered around "why do I have to install all this stuff" and spend time learning about 3 commands to contribute.

Quite frankly there isn't even a standardized approach to git, and oh the messes I've seen because of it, or people do "topic" branches, but what that means, and how it's managed, varies. What is master anyways? it's not so much that I find that people are having a problem with dzil actually (if they've decided not to hate at it) but rather git. They are astonished that the default branch can be something other than master. They don't bother to do a git log -p after committing, they don't turn color on so they can see extra whitespace in their diffs, then get fussy when there tests don't pass Test::EOL, and they didn't want to run dzil test to see that.

Heck, I remember when I had to spend time convincing people git was a good idea, I still have some people telling me it's too hard, and makes things too complicated, it increases the barrier to entry. It's a constant battle between increasing the barrier to entry, and simplifying maintenance. One could just go to having all the files and uploading tarballs... and using a tarball revision system, but that makes more work for the maintainer, IMO. I think that the increased barrier to entry, with generally higher quality distributions is worth it.

Recently I've added TravisCI (still potentially working out some kinks) this should have the benefit of running your patches against a newly generated test suite, without you installing Dist::Zilla.

Also there's a certain problem of, how does one deal with a new contributor when their tests do not sufficiently pass the test suite, especially when it's something silly like whitespace, or an obvious false positive on Perl::Critic. I think Travis might help me with this too, because then it will automagically show up, and I don't have to bring it up.

As a side note, I might have to borrow some of @karenetheridge's contributing, as it seems it might be useful to give those hand full of commands in the CONTRIBUTING file.

from file-chmod.

I'm sure you're right that the tools work, and the users need to learn to use
them properly. And if your vision of higher-quality distributions through
more productive authors and maintainers is realized, then that will tend to
promote Perl in the dev community even if there is some pain getting started with it.
Here's hoping....

Sure would go smoother, though, if there was a bit more hand-holding. By the
end of January we'll have updated versions of all four of the O'Reilly
"standard" Perl texts. As far as I can see, they have a grand total of eight
lines on Dist::Zilla. (For that matter, barely more on Moose, but at least
Moose::Manual::* is very good, IMO.) Dzil.org is way too oriented to
converting old-timers to D::Z, and frankly just way too damn vague. Here's
the info on what you get for having [PodWeaver] in your dist.ini:

This will add sections for each module's name, abstract, version, authors,
license, and a bunch of other bits in the middle like the synopsis and
methods. It will let you use the commands =method, =attr, and =func to set up
self-organizing sections for methods, attributes, and functions.

Thanks. Guess I'll go RTFM to find out exactly what all that means.
Except, of course, I won't because LOL, so it's off to read Yanick's "Taming
Pod::Weaver", followed by some self-guided experimentation.

Sorry for the rant in your "issues" section. But maybe that's why it's called "issues".

And BTW, I think that @karenetheridge's CONTRIBUTING is
stellar and you should definitely emulate/steal it.

from file-chmod.

Yeah, recently discussed with @karenetheridge that dzil.org perhaps should get a "Contributing to a dzil Distribution" section. which probably should closely resemble some sections of her CONTRIBUTING, mine more closely reflects git.git's HACKING File (from ~3 years ago)

from file-chmod.