normally you'd have
[pluginA]
[pluginB]
[pluginC]
[pluginXTests]
[pluginYTests]
[pluginZTests]
and one of them doesn't work on your system (for whatever reason), well you can just do this.
[pluginA]
[pluginB]
[pluginC]
;[pluginXTests]
[pluginYTests]
[pluginZTests]
the
; is a comment in ini, now dzil won't use that plugin. But people will say well you don't want to do that of course I want that plugin enabled. Here's why you may not temporarily. Casual user X has a bug in /your/ module that's using dzil, they code up a patch, and they want to run your test suite. The can't, because [pluginXTests] won't even install properly on their system due to a non perl dependency. They could have just commented it out, but now because you've used this PluginBundle it become difficult. They can't just comment it out.They might be able to
[@Filter]
-bundle = @USERNAME
-remove = pluginXTests
IF they can get your bundle installed in the first place. This requires them find a way to install your Bundle without installing said broken module.
as I stated at the top my problem is with [PodSpellingTests] it itself isn't broken, but it's dependency Test::Spelling is on some systems, due to the lack of a 'spell' command.
Yes I know there's a workaround... I could just copy a shell script into my path that makes aspell or something work, but really that's not the right solution. No I'm not packaging GNU Spell for my system either, the other spell programs work much better (from what I've read).
Also I find modules with your own username in them to be fairly obnoxious.
If you'd like less code, can't we start making a few more generic Bundle's? I wouldn't minde seeing a Bundle for Tests, and maybe another one for other stuff. I think 1/3 of the lines in my dist.ini's are tests.
I don't agree at all, and I think your reaction is based on a wrong assumption.
ReplyDeleteYou are assuming that you need Dist::Zilla to contribute to a project that uses Dist:Zilla and thats just not true.
You can use prove to run the tests, no need to run dzil test, thats my job.
you can't if they haven't been generated. with dzil a large number of tests aren't created before dzil build is run (which won't build if all the module aren't there). and if they aren't using something like CommitBuild they aren't there.
ReplyDeleteanywho I tagged with unpopular opinion because most people won't agree. I don't actually expect anyone to stop doing it. Although if I'm lucky maybe they'll remove PodSpellingTests from their bundle and add it by hand so it's easier to remove.
ReplyDeleteAlso with all of the pod and code generation how can I be sure that my code is good if all I do is run prove? heck the module might not even work the same in some cases if I don't dzil build and then test.
ReplyDelete@melo
ReplyDeleteI don't agree at all with you. the full-test target (no matter how it is invoked on your local reinvent of EU::MM) is a mandatory responsibility of the contributor. Slapping code together and throwing it over the fence without looking is, to put it mildly, inconsiderate. By saying "That's my job" you are doing a great disservice to the community, by suggesting it is ok to contribute without a full test-run.
For once, I agree with you.
ReplyDeleteI was trying to contribute to some project some weeks ago and, unfortunately, it used a dzil bundle which included Git plugins. I'm on Windows and they just don't work here.
I ended up changing the dist.ini file to explicitely use the plugins instead of the bundle and commented the Git-related ones.
It was mostly an issue because the tests were also auto-generated and the bug I was trying to fix was related to the tests itself.
So, instead of contributing a fix, I was only able to contribute a bug report (which the author fixed, and I'm very glad he was very nice about it).
dzil is very nice, but I don't if I like the idea of different line numbers and files in the repository vs. the CPAN release. I'm still trying to fully digest this idea.
I remember one of the main mentioned drawbacks of source filters were the possibilities of error messages in the wrong lines. And now, everyone seems to embrace this without hesitation.
Actually, I have to agree with your headline title as well, but for another reason.
ReplyDeleteMostly it is because the Dist::Zilla::PluginBundle::USERNAME doesn't actually say anything about its intention. It only says use Dist::Zilla as this person does, but what does that actually mean? If you don't know the person it doesn't really tell you anything.
I'd much more prefer PluginBundles that actually advocate certain types of standards or behaviors.
Some PluginBundles that I can think of just immediately are these: @GitHub, @RT, @PBP, @AutoDoc, @Moose. I think most of these are explains themselves, but I can give a small example of what I'd expect them to do.
@GitHub would obviously enable @Git, but also ReadmeMarkdownFromPod, CopyReadmeFromBuild and enable relevant MetaResources to point to obvious GitHub-related resources.
@RT could set MetaResources appropriately and possible include the [Support] podweaver section.
@PBP could include all the suggested author/release-tests and autorun critic and tidy on the code before commit to ensure consistent style.
@AutoDoc could enable a good bunch of typical PodWeaver sections that create a very consistent POD according to existing perl style guidelines with as much autogeneration as possible.
@Moose would enable boilerplate documentation via introspection (so that you don't really need to document what constraints an attribute has, if it is read only or read-write, you'd only have to actually write the documentation for it, not the signature documentation. Technically it could even be able to auto-document inherited/composed attributes, which would be quite useful.
Well, I guess you probably get my point by now...
The responsibility of the contributors, such as it is, is decided by the person who will decide whether to accept contributions.
ReplyDeleteI don't expect anyone to do anything beyond make sure "prove -lr t" passes. Others might demand that all tests pass. It's up to the project lead to make project-scoped decisions, not the open source community at large to make one for every project.
I agree that opaque bundles are a pain. I don't have a great answer yet. I think we'll see something better emerge over time.
I want to state that I don't have problems with at all with 'self contained' bundle's like [@Git], or [@Basic] which doesn't pull in another bunch of Plugins. If you create a set of plugins in one dist and want to include a bundle that's fine.
ReplyDeleteI think @Robin has hit the nail on the head here. except that ::USERNAME does convey a purpose, these are the personalized settings of person who uses USERNAME. I'm not comfortable filing a bug against that, and I certainly don't think anyone but USERNAME cares about those settings.
I can understand people wanting to shorten dist.ini it seems often it's filled with a lot of... just noise. I think perhaps the way is to create more Bundle's that say something and have a specific purpose.
@Ricardo In the specific patch I did last night I hadn't had a chance to talk to the author yet. So I've no idea what he'd have wanted. I just fired off the patch anyways. I think he ended up just using his own. but to clarify this specific module had no tests of its own.
I think Git::CommitBuild does a decent job of putting the source into the repository. It could be better though, as a git power user I think I'll see what I can do to make a module similar to it that's better.
although pending this discussion I won't be using Prepender to insert boilerplate code anymore. The behavior of a module shouldn't change pending on whether it's been built, docs and comments don't really change that behavior.
PluginBundles are not perfect, but the benefits outweigh the drawbacks. If you maintain more than a handful of CPAN modules, having a pluginbundle *greatly* simplifies the dist.ini file for each distribution you maintain.
ReplyDeleteWhat I have usually done when patching other modules that use Dist::Zilla is to simply replace the plugins in dist.ini so that it uses my own plugin bundle. That will generally at least get things rolling enough so that I can run the test suite. Its a bit of a headache, but I'll put up with it because I realize that it makes things so much easier for the author.
@Peter Rabbitson:
ReplyDeleteI have a different view: my software, my rules about what a contributor is supposed to do. If you want your contributors to run the full test suite, then you should make it easy for them to do it.
In my case, prove -lr t is enough, and I don't have any problems with contributions that pass those tests.
YMMV.
@xenoterracide:
All the tests I expect contributors to run are provided in the t/ directory.
The generated tests are useful for the distributor, or the person that will make a CPAN release.
I accept that you don't like them, but they are very useful and a time saver.
I like those tests... what I don't like is personalized bundle's read my latest blog post. I like tabs but a lot of other people don't so in dists that aren't mine... the NoTabsTests is a good thing... it'll catch me if I forget to do :se et in my editor... but if I can't run that test because someone bundled up everything with some tests I can't run period... (podspelling) as I've pointed out makes it very difficult to get around. Not using personalized bundle's should solve most of my complaints.
ReplyDeletealso not 100% but I think prove -lr ends up running tests against my installed library... meaning it would pass because it wouldn't run against my patch. dzil test doesn't have that issue... I'd have to run PERL5LIB="lib" prove -lr to do that I believe... (I don't know how all that works atm).
anyways the dist that brought this up didn't have any non generated tests... so... what am I supposed to be running prove against?