Bug #100938 for Mac-FSEvents: Move pod and perlcritic tests into xt/

Tue Dec 16 01:29:10 2014 preaction [...] cpan.org - Ticket created

Subject:

Move pod and perlcritic tests into xt/

The current convention is for the kind of soft tests like 02pod.t 03podcoverage.t and 04critic.t to be placed into xt/ so that a cpan install could not possibly break if those tests do. They already don't get run without the dependent module, and we'd be able to remove that check, because if you're running them, you need to have the prereqs. I can make a new make target that will run the extra tests, or I can see about adopting one of the cpan module management frameworks (I'm partial to Dist::Zilla, but it's a big hairy box of crazy to get it all working and debugged properly, so I'm not going to impose it on anyone).

Tue Dec 16 16:04:13 2014 RHOELZ [...] cpan.org - Correspondence added

On Tue Dec 16 01:29:10 2014, preaction wrote: Show quoted text

> The current convention is for the kind of soft tests like 02pod.t > 03podcoverage.t and 04critic.t to be placed into xt/ so that a cpan > install could not possibly break if those tests do. They already don't > get run without the dependent module, and we'd be able to remove that > check, because if you're running them, you need to have the prereqs. > > I can make a new make target that will run the extra tests, or I can > see about adopting one of the cpan module management frameworks (I'm > partial to Dist::Zilla, but it's a big hairy box of crazy to get it > all working and debugged properly, so I'm not going to impose it on > anyone).

I'm very much up for moving those tests into xt. Moving Mac::FSEvents to Dist::Zilla has been on my TODO list for a while; I just haven't taken the time to do so. I would be delighted if you could do this! I might end up refactoring the resulting dist.ini to use my personal author bundle, but that can come later.

Tue Dec 16 16:04:13 2014 The RT System itself - Status changed from 'new' to 'open'

Wed Dec 17 00:22:26 2014 preaction [...] cpan.org - Correspondence added

On Tue Dec 16 16:04:13 2014, RHOELZ wrote: Show quoted text

> On Tue Dec 16 01:29:10 2014, preaction wrote:

> > The current convention is for the kind of soft tests like 02pod.t > > 03podcoverage.t and 04critic.t to be placed into xt/ so that a cpan > > install could not possibly break if those tests do. They already > > don't > > get run without the dependent module, and we'd be able to remove that > > check, because if you're running them, you need to have the prereqs. > > > > I can make a new make target that will run the extra tests, or I can > > see about adopting one of the cpan module management frameworks (I'm > > partial to Dist::Zilla, but it's a big hairy box of crazy to get it > > all working and debugged properly, so I'm not going to impose it on > > anyone).

> > I'm very much up for moving those tests into xt. > > Moving Mac::FSEvents to Dist::Zilla has been on my TODO list for a > while; I just haven't taken the time to do so. I would be delighted > if you could do this! I might end up refactoring the resulting > dist.ini to use my personal author bundle, but that can come later.

I'm against author bundles on principle. Too much potential for breakage-at-a-distance. That said, I can copy/paste my dist.ini and we can start from there (and you can adjust to your releasing needs). That also said, I've never done a Dist::Zilla dist that needs XS, so that might be a thing to want to learn...

Wed Dec 17 00:28:26 2014 RHOELZ [...] cpan.org - Correspondence added

On Wed Dec 17 00:22:26 2014, preaction wrote: Show quoted text

> On Tue Dec 16 16:04:13 2014, RHOELZ wrote:

> > On Tue Dec 16 01:29:10 2014, preaction wrote:

> > > The current convention is for the kind of soft tests like 02pod.t > > > 03podcoverage.t and 04critic.t to be placed into xt/ so that a cpan > > > install could not possibly break if those tests do. They already > > > don't > > > get run without the dependent module, and we'd be able to remove > > > that > > > check, because if you're running them, you need to have the > > > prereqs. > > > > > > I can make a new make target that will run the extra tests, or I > > > can > > > see about adopting one of the cpan module management frameworks > > > (I'm > > > partial to Dist::Zilla, but it's a big hairy box of crazy to get it > > > all working and debugged properly, so I'm not going to impose it on > > > anyone).

> > > > I'm very much up for moving those tests into xt. > > > > Moving Mac::FSEvents to Dist::Zilla has been on my TODO list for a > > while; I just haven't taken the time to do so. I would be delighted > > if you could do this! I might end up refactoring the resulting > > dist.ini to use my personal author bundle, but that can come later.

> > I'm against author bundles on principle. Too much potential for > breakage-at-a-distance. That said, I can copy/paste my dist.ini and we > can start from there (and you can adjust to your releasing needs). > That also said, I've never done a Dist::Zilla dist that needs XS, so > that might be a thing to want to learn...

I understand; I'm against using any bundle but my own. =P Starting with a base dist.ini would be a good start, and we can work from there. As far as XS goes, I recently converted Inline::Lua to use Dist::Zilla; you may find my dist.ini file for that useful: https://github.com/hoelzro/inline-lua/blob/master/dist.ini

Wed Dec 17 02:42:50 2014 preaction [...] cpan.org - Correspondence added

On Wed Dec 17 00:28:26 2014, RHOELZ wrote: Show quoted text

> On Wed Dec 17 00:22:26 2014, preaction wrote:

> > On Tue Dec 16 16:04:13 2014, RHOELZ wrote:

> > > On Tue Dec 16 01:29:10 2014, preaction wrote:

> > > > The current convention is for the kind of soft tests like 02pod.t > > > > 03podcoverage.t and 04critic.t to be placed into xt/ so that a > > > > cpan > > > > install could not possibly break if those tests do. They already > > > > don't > > > > get run without the dependent module, and we'd be able to remove > > > > that > > > > check, because if you're running them, you need to have the > > > > prereqs. > > > > > > > > I can make a new make target that will run the extra tests, or I > > > > can > > > > see about adopting one of the cpan module management frameworks > > > > (I'm > > > > partial to Dist::Zilla, but it's a big hairy box of crazy to get > > > > it > > > > all working and debugged properly, so I'm not going to impose it > > > > on > > > > anyone).

> > > > > > I'm very much up for moving those tests into xt. > > > > > > Moving Mac::FSEvents to Dist::Zilla has been on my TODO list for a > > > while; I just haven't taken the time to do so. I would be > > > delighted > > > if you could do this! I might end up refactoring the resulting > > > dist.ini to use my personal author bundle, but that can come later.

> > > > I'm against author bundles on principle. Too much potential for > > breakage-at-a-distance. That said, I can copy/paste my dist.ini and > > we > > can start from there (and you can adjust to your releasing needs). > > That also said, I've never done a Dist::Zilla dist that needs XS, so > > that might be a thing to want to learn...

> > I understand; I'm against using any bundle but my own. =P Starting > with a base dist.ini would be a good start, and we can work from > there. As far as XS goes, I recently converted Inline::Lua to use > Dist::Zilla; you may find my dist.ini file for that useful: > https://github.com/hoelzro/inline-lua/blob/master/dist.ini

[Test::LocalBrew] Ha! I should have known someone made something for this! We just started using Gradle at $work and set up something similar to this, but inside Gradle plugins where it isn't useful to regular Perl people. But yes, thanks, I'll spend some time figuring this out. Doesn't look as bad as I feared. And this time I have some better ideas about testing the dist.ini (I may only need to remove the UploadToCPAN plugin, especially since I'm only pushing to my fork, and not the real repo).

Wed Dec 17 08:35:10 2014 RHOELZ [...] cpan.org - Correspondence added

On Wed Dec 17 02:42:50 2014, preaction wrote: Show quoted text

> On Wed Dec 17 00:28:26 2014, RHOELZ wrote:

> > On Wed Dec 17 00:22:26 2014, preaction wrote:

> > > On Tue Dec 16 16:04:13 2014, RHOELZ wrote:

> > > > On Tue Dec 16 01:29:10 2014, preaction wrote:

> > > > > The current convention is for the kind of soft tests like > > > > > 02pod.t > > > > > 03podcoverage.t and 04critic.t to be placed into xt/ so that a > > > > > cpan > > > > > install could not possibly break if those tests do. They > > > > > already > > > > > don't > > > > > get run without the dependent module, and we'd be able to > > > > > remove > > > > > that > > > > > check, because if you're running them, you need to have the > > > > > prereqs. > > > > > > > > > > I can make a new make target that will run the extra tests, or > > > > > I > > > > > can > > > > > see about adopting one of the cpan module management frameworks > > > > > (I'm > > > > > partial to Dist::Zilla, but it's a big hairy box of crazy to > > > > > get > > > > > it > > > > > all working and debugged properly, so I'm not going to impose > > > > > it > > > > > on > > > > > anyone).

> > > > > > > > I'm very much up for moving those tests into xt. > > > > > > > > Moving Mac::FSEvents to Dist::Zilla has been on my TODO list for > > > > a > > > > while; I just haven't taken the time to do so. I would be > > > > delighted > > > > if you could do this! I might end up refactoring the resulting > > > > dist.ini to use my personal author bundle, but that can come > > > > later.

> > > > > > I'm against author bundles on principle. Too much potential for > > > breakage-at-a-distance. That said, I can copy/paste my dist.ini and > > > we > > > can start from there (and you can adjust to your releasing needs). > > > That also said, I've never done a Dist::Zilla dist that needs XS, > > > so > > > that might be a thing to want to learn...

> > > > I understand; I'm against using any bundle but my own. =P Starting > > with a base dist.ini would be a good start, and we can work from > > there. As far as XS goes, I recently converted Inline::Lua to use > > Dist::Zilla; you may find my dist.ini file for that useful: > > https://github.com/hoelzro/inline-lua/blob/master/dist.ini

> > [Test::LocalBrew] > > Ha! I should have known someone made something for this! We just > started using Gradle at $work and set up something similar to this, > but inside Gradle plugins where it isn't useful to regular Perl > people. > > But yes, thanks, I'll spend some time figuring this out. Doesn't look > as bad as I feared. And this time I have some better ideas about > testing the dist.ini (I may only need to remove the UploadToCPAN > plugin, especially since I'm only pushing to my fork, and not the real > repo).

Sounds good!