But if someone
else helps you install the machine, then you don't actually need the level,
if they bring theirs and use it for the install.
I think that the build_requires/test_requires distinction *is* important, if
it can be made, as it eases the lives of anyone wishing to package up
modules,
I think actually you've bought a self-levelling washing machine and
there should be no need for a level but if you value your kitchen and
your clothes you have your own level,
F
On 9/12/05, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 11, 2005 at 12:35:43PM -0500, Andy Lester wrote:
>
Let's play devil's advocate. On the positive side, if you bundle the
testing module, you can be more certain that your tests will work if the
new version of the bundled module breaks backward compatibility, whether
by design or by accident... If I *know* that my module tests properly
with Test:
Chromatic wrote:
On Mon, 2005-09-12 at 09:36 +1000, Adam Kennedy wrote:
If you do realize, but it takes you 3 days to update once mainline
was fixed, and it takes mainline 3 days to update once Joe Random's
patch was submitted, why should new users from these 3 days get a
buggy, outdated versi
Andy Lester wrote:
On Sep 11, 2005, at 7:25 PM, chromatic wrote:
I don't feel as confident as you do that if the tests all passed on your
machine that they'll automatically pass everywhere.
THIS is my biggest point. It's not about the quality of the code so
much as making sure the code
On Sun, Sep 11, 2005 at 12:35:43PM -0500, Andy Lester wrote:
> >Usually, Test::* modules are only used for the test phase.
>
> I really don't understand the idea of "only used for the test phase",
> as if the tests don't matter, or if there are levels of failure.
> Either they install OK on t
On Sep 11, 2005, at 7:25 PM, chromatic wrote:
I don't feel as confident as you do that if the tests all passed on
your
machine that they'll automatically pass everywhere.
THIS is my biggest point. It's not about the quality of the code so
much as making sure the code fits with the target
On Mon, Sep 12, 2005 at 04:22:05 +0300, Yuval Kogman wrote:
> It still promotes:
I forgot:
* unnecessary rolling and rerolling of distribution tarballs
with no real merit but updating the bundled code causes
version space pollution, and makes users who update annoyed
On Mon, Sep 12, 2005 at 09:36:28 +1000, Adam Kennedy wrote:
>
> >If you get hit by a truck and someone updates Test::Moose to take
> >care of a bug, who will update your bundled version?
>
> Simple. Because I don't bundle it by hand, Module::Install does it. Bundling
> things by hand would be WA
On Mon, 2005-09-12 at 09:36 +1000, Adam Kennedy wrote:
> > If you do realize, but it takes you 3 days to update once mainline
> > was fixed, and it takes mainline 3 days to update once Joe Random's
> > patch was submitted, why should new users from these 3 days get a
> > buggy, outdated version wh
If you get hit by a truck and someone updates Test::Moose to take
care of a bug, who will update your bundled version?
Simple. Because I don't bundle it by hand, Module::Install does it.
Bundling things by hand would be WAY too much work.
The next time someone else rolls the build, it autom
On Sun, Sep 11, 2005 at 23:51:56 +1000, Adam Kennedy wrote:
> I've found that by using Module::Install, I can often just bundle those small
> miscellaneous testing modules, and occasionally a few of their dependencies.
>
> And for something simple as "the tests don't generate warnings", I would
On 9/11/05, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> And for something simple as "the tests don't generate warnings", I would
> think "module has excessive dependencies" is a bug in Test::Deep, rather
> than a more general problem.
I'd say "obvious", "necessary" and "a simple idea" but if you thi
On Sun, Sep 11, 2005 at 01:52:41PM -0400, Christopher H. Laco wrote:
> I've always thought tests passing should be a requisite of make by
> default. Make fails if tests fail. There should of course be a
> -skiptests to opt out of testing for those who insist on not doing it,
> but for the most p
On Sun, Sep 11, 2005 at 07:01:50AM -0400, Randy W. Sims wrote:
> The current MakeMaker has support for adding arbitrary data to META.yml,
> so it can also provide info to installers. However, I doubt MakeMaker
> itself will every know anything about or use such requirements &
> recommendations.
I've found that by using Module::Install, I can often just bundle those
small miscellaneous testing modules, and occasionally a few of their
dependencies.
And for something simple as "the tests don't generate warnings", I would
think "module has excessive dependencies" is a bug in Test::Deep,
Andy Lester wrote:
>> yeah, well, you could say that. last time I installed my washer I said
>> "looks pretty level to me, but I know where my level is if it makes a
>> racket"
>
>
> That's fine, but I'm still not shipping my washing machines without
> explicit instructions to level the dam
yeah, well, you could say that. last time I installed my washer I
said
"looks pretty level to me, but I know where my level is if it makes
a racket"
That's fine, but I'm still not shipping my washing machines without
explicit instructions to level the damn thing. Similarly, I'm not
maki
Andy Lester wrote:
>> Usually, Test::* modules are only used for the test phase.
>
>
> I really don't understand the idea of "only used for the test phase",
there is clearly a distinction between the code required for a given module
to compile and run in a production environment and the code r
Andy Lester wrote:
Usually, Test::* modules are only used for the test phase.
I really don't understand the idea of "only used for the test phase",
as if the tests don't matter, or if there are levels of failure.
Either they install OK on the target system, and you can use them with
con
Usually, Test::* modules are only used for the test phase.
I really don't understand the idea of "only used for the test phase",
as if the tests don't matter, or if there are levels of failure.
Either they install OK on the target system, and you can use them
with confidence, and they've
> > Either they're valuable enough that you install their prerequisites or
> > they're not.
>
> But how am I supposed to find this out? I dont even know whether the
> required modules are used for the tests only, without digging through the
> source...
Usually, Test::* modules are only used for t
You wrote:
> This is a mini-rant on how complex the tesing world for Perl modules has
> become. It starts harmless, like you want to install some module. This
> time it was CPAN-Depency.
>
> Since for security reasons your Perl box is not connected to the net, you
> fetch it and all dependencies f
Fergal Daly wrote:
There is a genuine problem here though and that's the fact that MakeMaker
and possibly Module::Build don't allow you to specify testing requirements
separately from building requirements and run time requirements but most
people don't ever see it thanks to CPAN.pm.
The curr
On Sat, Sep 10, 2005 at 07:56:11PM +0100, Fergal Daly wrote:
> What do you mean "has become" all the modules you encountered are at least 2
> years old but apart form anything that's a bit like coplaining about how
> complex the world of coputers has become, it used to be that I could just
> swi
They add some value to me (show that at least something works).
>>>
>>>Either they're valuable enough that you install their prerequisites or
>>>they're not.
>
>
> But how am I supposed to find this out? I dont even know whether the
> required modules are used for the tests only, without di
-BEGIN PGP SIGNED MESSAGE-
On Saturday 10 September 2005 21:20, Tels wrote:
> Moin,
btw, here is an idea that occured to me:
There is a reason that not every little function in Test::More is it's own
module on CPAN: it makes it much easier to maintain and use them.
So maybe it would be
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Saturday 10 September 2005 21:00, chromatic wrote:
> On Sat, 2005-09-10 at 20:21 +0200, Tels wrote:
> > On Saturday 10 September 2005 19:27, chromatic wrote:
> > > You can always just not run the tests and hope that things work.
> > > If the tests don'
On 9/10/05, Tels <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
>
> Moin,
>
> you are in a maze of Test modules, all looking alike. You are likely being
> beaten by a dependecy.
>
> This is a mini-rant on how complex the tesing world for Perl modules has
> become. It starts
On Sat, 2005-09-10 at 20:21 +0200, Tels wrote:
> On Saturday 10 September 2005 19:27, chromatic wrote:
> > You can always just not run the tests and hope that things work. If
> > the tests don't add any value to you, ignore them.
> They add some value to me (show that at least something works).
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Saturday 10 September 2005 19:27, chromatic wrote:
> On Sat, 2005-09-10 at 17:40 +0200, Tels wrote:
> > I am all for putting often used stuff into extra modules, but I think
> > this has gone way to far, especially the user will go through all
> > this
On Sat, 2005-09-10 at 17:40 +0200, Tels wrote:
> I am all for putting often used stuff into extra modules, but I think this
> has gone way to far, especially the user will go through all this just so
> that Random-Module-0.01 can run it's freaky test suite
You can always just not run the te
Hi,
Tels wrote:
Since for security reasons your Perl box is not connected to the net, you
fetch it and all dependencies from CPAN and transfer them via sneaker net
and USB stick. It includes some gems like:
A solution to the sneakernet problem is to have your own CPAN mirror,
either on a mac
On Sat, Sep 10, 2005 at 05:40:54PM +0200, Tels wrote:
> This is a mini-rant on how complex the tesing world for Perl modules has
> become. It starts harmless, like you want to install some module. This
> time it was CPAN-Depency.
>
> Since for security reasons your Perl box is not connect
-BEGIN PGP SIGNED MESSAGE-
Moin,
you are in a maze of Test modules, all looking alike. You are likely being
beaten by a dependecy.
This is a mini-rant on how complex the tesing world for Perl modules has
become. It starts harmless, like you want to install some module. This
time it wa
35 matches
Mail list logo
