On Sat Sep 01 13:21:30 2012, RIBASUSHI wrote:
Show quoted text> On Sat Sep 01 13:06:38 2012, SHLOMIF wrote:
> > Hi ribasushi,
> >
> > > How is this different from Test::EOL?
> >
> > Well, I was not aware of Test::EOL previously, and I was not able to
> > find it or something similar on this MetaCPAN search:
> >
> >
https://metacpan.org/search?q=trailing%20space
> >
> > (which Test-TrailingSpace is now the no. 1 result).
>
> And that is the main problem. If more people get to use your module,
> we
> will end up with a growing set of modules depending on your version,
> while dists already using Test::EOL are extremely unlikely to switch
> (there is no incentive). The result[1] is very well described here:
>
http://www.modernperlbooks.com/mt/2012/08/speeding-up-my-test-suite-
> by-25.html
>
OK, I read your reasoning, and the footnote, and I should note that it
is in part mitigated by the fact that I recommend using the following
pattern:
eval "use Test::TrailingSpace";
if ($@)
{
plan skip_all => "Test::TrailingSpace required for trailing space
test.";
}
else
{
plan tests => 1;
}
This tries to load Test::TrailingSpace, so it's not needed to be
specified as a dependency of the tested modules and need only be used
in-house.
Furthermore, I should note that the name "Test::EOL" is delightfully
non-descriptive of its functionality as a way to detect the presence of
trailing whitespace, and that it is not present in the first 20 or so
results in a MetaCPAN search for "trailing space":
https://metacpan.org/search?q=trailing%20space . So if I remove my
module, what happens is that someone else may eventually write a similar
one, and then you'll again have to file a bug. So I'd rather point
someone at Test::EOL somewhere prominently on Test::TrailingSpace.
Show quoted text> >
> > Anyway, one advantage that Test-TrailingSpace has over Test::EOL is
> that
> > it accepts a regular expression of filenames to search for, which
> > Test::EOL does not appear to have (it can only search in individual
> > files or in an explicit list of filenames).
>
> This is something that you can easily fix with a patch to Test::EOL
>
I can, but I was not aware of Test::EOL's presence when I've written
Test::TrailingSpace, so I cannot help that I invented a somewhat better
wheel. Anyway, I will consider contributing to Test::EOL.
Show quoted text> > Another minor difference is
> > the fact that Test-TrailingSpace is under the MIT/X11 licence while
> > Test::EOL is under the same terms as Perl itself.
>
> This is actually a similar disadvantage, except this time we are
> talking
> about diverging license trees. It is practically impossible to get a
> CPAN dep chain that is free of "as perl itself" licenses. Given that
> you
> are in practice introducing another license into the dep-chain[2]. Ask
> e.g. the Debian guys how they feel about that.
The Debian Perl team were happy to prepare Debian packages for some of
my modules, which were also under the MIT/X11 licence. I believe the
main problem is the licensing of "as perl itself", because the various
versions of the GPL licence are not compatible with many licences ( see
http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses )
and pose some restrictions, and the original Artistic License is not
considered a free software licence by the Free Software Foundation or by
Red Hat. The X11 licence is compatible with all the open source licences
that I'm aware of, and explicitly allows for sublicensing into any other
licence, so it would have been a better choice for the licence of Perl,
and is a better choice for licensing CPAN modules in the present.
As usual, I am not a lawyer ("IANAL")/etc.
For more information see:
*
http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as-perl-itself.html
*
http://perlbuzz.com/2008/04/the-problem-with-same-terms-as-perl-licensing.html
*
http://perlbuzz.com/2010/06/artistic-license-20-makes-dual-license-boilerplate-unnecessary.html
Regards,
-- Shlomi Fish
RT for rt.cpan.org