or create them. Here’s the problem…. (short version is Don’t put PodSpellingTests in them)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 = pluginXTestsIF 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.– This work by Caleb Cushing is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.