FAQ
Hi guys,
I'm having trouble getting Catalyst to install (via CPAN) on a fresh
Debian Etch install.
The problem is the dependency Mouse (0.11) fails its unit tests there.
(I'd guess due to the older versions of some core packages).

I've raised http://rt.cpan.org/Ticket/Display.html?idA254.

Catalyst::Action::RenderView (first module which was wanting Mouse)
itself seems to pass its own unit tests after Mouse is force-installed,
though.

Toby

--
Strategic Data Pty Ltd
Ph: 03 9340 9000

Search Discussions

  • Aristotle Pagaltzis at Nov 27, 2008 at 2:55 am

    * Toby Corkindale [2008-11-27 01:55]:
    The problem is the dependency Mouse (0.11) fails its unit tests
    there.
    That?s really the sole solid argument against a flamboyant
    use-the-CPAN attitude: you end up pulling in heaps of bloat
    because none of the stuff was written to form a coherent whole:
    every author uses their own favourite way of doing some common
    thing so you get four different OO frameworks of varying heft,
    two different YAML modules, every JSON module there is, etc.,
    all loaded into the same perl process. What a waste.

    Case in point, Mouse is essentially Moose Light. Since Catalyst
    itself is becoming Moose-based, is there *any* reason to use
    Mouse instead? I suppose if it automatically stubs itself into
    a Moose loader where Moose is available, that would be not *too*
    bad, but it?s still a pointlessly added dependency.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Toby Corkindale at Nov 27, 2008 at 3:18 am

    Aristotle Pagaltzis wrote:
    * Toby Corkindale [2008-11-27 01:55]:
    The problem is the dependency Mouse (0.11) fails its unit tests
    there.
    That?s really the sole solid argument against a flamboyant
    use-the-CPAN attitude: you end up pulling in heaps of bloat
    because none of the stuff was written to form a coherent whole:
    every author uses their own favourite way of doing some common
    thing so you get four different OO frameworks of varying heft,
    two different YAML modules, every JSON module there is, etc.,
    all loaded into the same perl process. What a waste.

    Case in point, Mouse is essentially Moose Light. Since Catalyst
    itself is becoming Moose-based, is there *any* reason to use
    Mouse instead? I suppose if it automatically stubs itself into
    a Moose loader where Moose is available, that would be not *too*
    bad, but it?s still a pointlessly added dependency.
    According to the Mouse docs, Mouse supports the most commonly used
    features of Moose, but runs in 25% of the time.
    I'm happy if the Catalyst crowd has decided to use a
    performance-optimised version of a module, but it seems like Mouse has
    had less testing exposure to "production" systems. (ie. The ancient
    Perl/CPAN modules running on debian, rhel, etc)
    (I note that Moose itself passes tests on Debian stable)

    Toby


    --
    Strategic Data Pty Ltd
    Ph: 03 9340 9000
  • Aristotle Pagaltzis at Nov 27, 2008 at 6:58 am

    * Toby Corkindale [2008-11-27 04:25]:
    Aristotle Pagaltzis wrote:
    Case in point, Mouse is essentially Moose Light. Since
    Catalyst itself is becoming Moose-based, is there *any*
    reason to use Mouse instead? I suppose if it automatically
    stubs itself into a Moose loader where Moose is available,
    that would be not *too* bad, but it?s still a pointlessly
    added dependency.
    According to the Mouse docs, Mouse supports the most commonly
    used features of Moose, but runs in 25% of the time. I'm happy
    if the Catalyst crowd has decided to use a
    performance-optimised version of a module, but it seems like
    Mouse has had less testing exposure to "production" systems.
    (ie. The ancient Perl/CPAN modules running on debian, rhel,
    etc) (I note that Moose itself passes tests on Debian stable)
    Sorry, I didn?t make myself clear enough. I meant that Catalyst
    is soon going to be loading Moose. So why should a 3rd party
    Catalyst extension load Mouse? OK, it might be a bit faster than
    Moose, but Moose will be loaded anyway, so any performance
    benefits will have to trade off against larger app instance
    processes, which probably adds up to a net negative for actual
    performance-hungry apps. Little is gained, therefore ? yet,
    another point of potential installation failure is added.

    Maybe there should be a list of modules that should be preferred
    for certain purposes when writing Catalyst extensions? Of course
    we don?t to *prescribe* any of them, since the main selling point
    of Catalyst is that cares more about being glue and about having
    an opinion. So if you want to glue something big like Template
    Toolkit or Mason into Catalyst you might have to accept modules
    which duplicate functionality that other dependencies already
    offer. But it might be good to say ?for tasks where you don?t
    already have a really strong opinion and where it?s up to you,
    please strongly consider using the following modules?. (The
    Catalyst Canon maybe, if you will.)

    It would certainly be an interesting exercise to go through the
    dependency chains of a few big Cat apps to see how much duplicate
    functionality and overlap they have. A union of the prereqs of a
    big pile of of Catalyst extensions could also serve as discussion
    basis for that suggested Canon.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Ian Sillitoe at Nov 27, 2008 at 11:43 am

    Maybe there should be a list of modules that should be preferred
    for certain purposes when writing Catalyst extensions? Of course
    we don't to *prescribe* any of them, since the main selling point
    of Catalyst is that cares more about being glue and about having
    an opinion. So if you want to glue something big like Template
    Toolkit or Mason into Catalyst you might have to accept modules
    which duplicate functionality that other dependencies already
    offer. But it might be good to say "for tasks where you don't
    already have a really strong opinion and where it's up to you,
    please strongly consider using the following modules". (The
    Catalyst Canon maybe, if you will.)
    I think this is a great idea - I know the flexibility that Catalyst offers
    is a big selling point, however
    I think lots of people new to Catalyst (or just new to a different area of
    Catalyst) want to know best practices, e.g. which modules have been tried
    and tested in a production environment, which modules are well accepted,
    written and supported, etc.

    Obviously TMTOWTDI but I'm very happy to take advice from people who have
    lots of experience in the field - if you're developing systems for
    production you'd be crazy not to.

    I guess there's:

    http://dev.catalystframework.org/wiki/recommended_plugins

    or something like:

    http://search.cpan.org/~perigrin/Task-Kensho-0.0.4/lib/Task/Kensho.pm


    Cheers,

    Ian





    --
    Ian Sillitoe
    CATH Team -- http://cathdb.info
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20081127/200a95d2/attachment.htm
  • Johan Lindström at Nov 28, 2008 at 1:31 am

    At 06:58 2008-11-27, Aristotle Pagaltzis wrote:
    According to the Mouse docs, Mouse supports the most commonly
    used features of Moose, but runs in 25% of the time. I'm happy
    I think that may be referring to startup time (and the Mouse POD
    refers to compile time actually).

    In the context of web apps, if you're interested in performance at
    all, you're obviously not going to use CGI. It's gonna be a
    persistent environment. So in that scenario, startup cost is irrelevant.

    I benchmarked a few OO/accessor modules, and Mouse was amongst the
    slowest ones. IIRC there's a 4:1 performance difference between Mouse
    and immutable Moose classes (mutable Moose classes is a disaster, a
    few percent slower than Mouse I think it was). So you make Moose
    classes immutable.

    The benchmark wasn't scientific or anything, basically just a new()
    with some of the default values overridden in the call + a getter
    access. I think Moose was something like 20% behind
    Class::Accessor::Fast and Spiffy was really fast.

    Like the Moose docs say, you pay for what you use. In this case, when
    I added type constraints they became the most expensive things beyond
    the basics, but still as performant as hand coding the validation.


    /J
  • Dave Rolsky at Nov 28, 2008 at 4:40 am

    On Fri, 28 Nov 2008, Johan Lindstr?m wrote:
    At 06:58 2008-11-27, Aristotle Pagaltzis wrote:
    According to the Mouse docs, Mouse supports the most commonly
    used features of Moose, but runs in 25% of the time. I'm happy
    I think that may be referring to startup time (and the Mouse POD refers to
    compile time actually).

    In the context of web apps, if you're interested in performance at all,
    you're obviously not going to use CGI. It's gonna be a persistent
    environment. So in that scenario, startup cost is irrelevant.

    I benchmarked a few OO/accessor modules, and Mouse was amongst the slowest
    ones. IIRC there's a 4:1 performance difference between Mouse and immutable
    Moose classes (mutable Moose classes is a disaster, a few percent slower than
    Mouse I think it was). So you make Moose classes immutable.

    The benchmark wasn't scientific or anything, basically just a new() with some
    of the default values overridden in the call + a getter access. I think Moose
    was something like 20% behind Class::Accessor::Fast and Spiffy was really
    fast.

    Like the Moose docs say, you pay for what you use. In this case, when I added
    type constraints they became the most expensive things beyond the basics, but
    still as performant as hand coding the validation.
    I'm pretty sure that Moose (especially when making one's classes
    immutable) has a much bigger _compile_ time hit than Mouse. OTOH, Moose's
    immutabilized constructor is faster than Mouse's.

    I think the optimal use case for Mouse is something in a process that gets
    started a lot (a CLI app, for example). In that case, the compile time
    savings can easily outweight the runtime loss.


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Tomas Doran at Nov 28, 2008 at 3:17 pm

    On 28 Nov 2008, at 01:31, Johan Lindstr?m wrote:
    At 06:58 2008-11-27, Aristotle Pagaltzis wrote:
    According to the Mouse docs, Mouse supports the most commonly
    used features of Moose, but runs in 25% of the time. I'm happyt.
    I benchmarked a few OO/accessor modules, and Mouse was amongst the
    slowest ones. IIRC there's a 4:1 performance difference between
    Mouse and immutable Moose classes (mutable Moose classes is a
    disaster, a few percent slower than Mouse I think it was). So you
    make Moose classes immutable.
    In this case (Action::RenderView), Mouse is used by Data::Visitor,
    which is used by RenderView just for trimming things out of the debug
    dump, so how fast it is or isn't really a concern, assuming that your
    application isn't an application to show how pretty Catalyst's debug
    dumps are, at least ;_)

    Cheers
    t0m
  • Zbigniew Lukasiak at Nov 27, 2008 at 9:05 am

    On Thu, Nov 27, 2008 at 3:55 AM, Aristotle Pagaltzis wrote:
    * Toby Corkindale [2008-11-27 01:55]:
    The problem is the dependency Mouse (0.11) fails its unit tests
    there.
    That's really the sole solid argument against a flamboyant
    use-the-CPAN attitude: you end up pulling in heaps of bloat
    because none of the stuff was written to form a coherent whole:
    every author uses their own favourite way of doing some common
    thing so you get four different OO frameworks of varying heft,
    two different YAML modules, every JSON module there is, etc.,
    all loaded into the same perl process. What a waste.

    Case in point, Mouse is essentially Moose Light. Since Catalyst
    itself is becoming Moose-based, is there *any* reason to use
    Mouse instead? I suppose if it automatically stubs itself into
    a Moose loader where Moose is available, that would be not *too*
    bad, but it's still a pointlessly added dependency.
    There is also Squirrel
    (http://search.cpan.org/~sartak/Mouse-0.11/lib/Squirrel.pm) - it loads
    Mouse unless Moose is already loaded (just citing the Synopsis).

    At the operating system level I've seen sometimes 'virtual packages'
    that decouple the services from packages that provide those services.
    So you can have a service 'sendmail' that actually is provided by the
    'postfix' package.
    This level of compatibility between libraries is rather exceptional -
    I think that Moose and Mouse are the only examples so far, but maybe
    it is time to start thinking about that. CatalystX::CRUD tries to
    work with both RDBO and DBIC - the effect is a bit too heavyweight for
    my liking, but it is a bold experiment.
  • Lars Balker Rasmussen at Nov 28, 2008 at 9:08 am

    On Thu, Nov 27, 2008 at 03:55:54AM +0100, Aristotle Pagaltzis wrote:
    Case in point, Mouse is essentially Moose Light. Since Catalyst
    itself is becoming Moose-based, is there *any* reason to use
    Mouse instead? I suppose if it automatically stubs itself into
    a Moose loader where Moose is available, that would be not *too*
    bad, but it???s still a pointlessly added dependency.
    While Data::Visitor depends on Mouse, it actually uses Squirrel (which
    is in the Mouse dist), which will fall back to the Moose already loaded
    by Catalyst. I assume most Mouse-users are smart enough to do this.

    And Data::Visitor isn't just for Catalyst-use, so our problem isn't theirs.
    --
    Lars Balker Rasmussen Consult::Perl
  • Aristotle Pagaltzis at Nov 30, 2008 at 8:56 am

    * Lars Balker Rasmussen [2008-11-28 10:20]:
    While Data::Visitor depends on Mouse, it actually uses Squirrel
    (which is in the Mouse dist), which will fall back to the Moose
    already loaded by Catalyst. I assume most Mouse-users are smart
    enough to do this.
    Yeah, that?s the least bad constellation.
    And Data::Visitor isn't just for Catalyst-use, so our problem
    isn't theirs.
    No, it still is a problem for Catalyst app users, because it
    still does add a point of potential installation failure. Of
    course the fact that this is caused by Data::Visitor rather than
    directly by Catalyst::Action::RenderView means there isn?t any
    easy answer. But it doesn?t change the conclusion that gluing
    together modules not designed with each other in mind has
    solid downsides for? parsimony in a general sense.

    Hrm. It bugs me that no good strategy for dealing with this is
    apparent.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Toby Corkindale at Nov 30, 2008 at 11:35 pm

    Lars Balker Rasmussen wrote:
    On Thu, Nov 27, 2008 at 03:55:54AM +0100, Aristotle Pagaltzis wrote:
    Case in point, Mouse is essentially Moose Light. Since Catalyst
    itself is becoming Moose-based, is there *any* reason to use
    Mouse instead? I suppose if it automatically stubs itself into
    a Moose loader where Moose is available, that would be not *too*
    bad, but it???s still a pointlessly added dependency.
    While Data::Visitor depends on Mouse, it actually uses Squirrel (which
    is in the Mouse dist), which will fall back to the Moose already loaded
    by Catalyst. I assume most Mouse-users are smart enough to do this.

    And Data::Visitor isn't just for Catalyst-use, so our problem isn't theirs.
    It kind of is still our problem, since if one writes an application for
    Catalyst, one hopes that the intended users can easily install it..
    which they can't on supposed "Stable" Linux installs, using Debian,
    RHEL, etc.

    If the automated install fails, people are likely to say "bah, this Perl
    thing sucks, let's go for that similar app written in PHP/Java/Ruby
    instead - at least it's simple to install!"

    PAR goes a little way to solving this, but then one needs to distribute
    multiple versions for all the platforms you support, and hope they have
    a decent PAR version too. (Again, Debian stable has issues.)

    Toby
  • Jonathan Rockway at Dec 1, 2008 at 12:10 am

    * On Sun, Nov 30 2008, Toby Corkindale wrote:
    If the automated install fails, people are likely to say "bah, this
    Perl thing sucks, let's go for that similar app written in
    PHP/Java/Ruby instead - at least it's simple to install!"
    Why do you care about what other people do? If these people can't even
    install a CPAN module, it's unlikely that they were going to become
    active contributors.
    PAR goes a little way to solving this, but then one needs to
    distribute multiple versions for all the platforms you support, and
    hope they have a decent PAR version too. (Again, Debian stable has
    issues.)
    This says more about Debian than PAR.

    --
    print just => another => perl => hacker => if $,=$"
  • Toby Corkindale at Dec 1, 2008 at 1:02 am

    Jonathan Rockway wrote:
    * On Sun, Nov 30 2008, Toby Corkindale wrote:
    If the automated install fails, people are likely to say "bah, this
    Perl thing sucks, let's go for that similar app written in
    PHP/Java/Ruby instead - at least it's simple to install!"
    Why do you care about what other people do? If these people can't even
    install a CPAN module, it's unlikely that they were going to become
    active contributors.
    Because not everyone is a contributor. In fact, *most* people are not
    contributors.
    Contributors come from being users first.
    If we lose the users, we will lose contributors in the long run, and
    Perl will disappear.
    PAR goes a little way to solving this, but then one needs to
    distribute multiple versions for all the platforms you support, and
    hope they have a decent PAR version too. (Again, Debian stable has
    issues.)
    This says more about Debian than PAR.
    I know :(
    But sysadmins seem to love the bloody thing, no matter how ancient and
    broken its so-called "stable" version is.

    It needs a tagline, like:
    "Debian - Stifling innovation since 1993"
    (Although really, they were quite innovative at first, so that's mean of
    me. I should point out that I understand that having a consistent,
    static base is very important to a lot of people.)

    Toby

    --
    I probably need a .sig that says my opinions are not those of my
    employers :)
  • Jay Shirley at Dec 1, 2008 at 2:36 am

    On Sun, Nov 30, 2008 at 4:10 PM, Jonathan Rockway wrote: [> * On Sun, Nov 30 2008, Toby Corkindale wrote:
    If the automated install fails, people are likely to say "bah, this
    Perl thing sucks, let's go for that similar app written in
    PHP/Java/Ruby instead - at least it's simple to install!"
    Why do you care about what other people do? If these people can't even
    install a CPAN module, it's unlikely that they were going to become
    active contributors.
    That is the worst ever response to a test failure... just terrible.
    This is a test failure at the core, because a version of a module down
    the chain wasn't tested.

    This is what CPAN Testers, in part, is designed to catch. Saying
    "they can't install a CPAN module" is an insult to the CPAN Testers
    effort and all the toolchain authors, too. There is a reason this
    stuff exists, it is so that CPAN modules are widely accessible.

    Welcome to the perl echo chamber...
  • Marcus Ramberg at Dec 1, 2008 at 9:05 am

    On Mon, Dec 1, 2008 at 3:36 AM, J. Shirley wrote:

    That is the worst ever response to a test failure... just terrible.
    This is a test failure at the core, because a version of a module down
    the chain wasn't tested.

    This is what CPAN Testers, in part, is designed to catch. Saying
    "they can't install a CPAN module" is an insult to the CPAN Testers
    effort and all the toolchain authors, too. There is a reason this
    stuff exists, it is so that CPAN modules are widely accessible.

    Welcome to the perl echo chamber...

    Hey, just because Jrockway is a emo who hates popularity doesn't mean we
    (the catalyst developers) don't care about installation failures. Matt has
    spent a lot of energy to make sure our dependency graph installs cleanly,
    for instance. And this issue has in fact already been resolved by the Mouse
    people, hasn't it?

    Marcus
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20081201/fcc8dd48/attachment.htm
  • Jay Shirley at Dec 1, 2008 at 3:36 pm

    On Mon, Dec 1, 2008 at 1:05 AM, Marcus Ramberg wrote:
    On Mon, Dec 1, 2008 at 3:36 AM, J. Shirley wrote:

    That is the worst ever response to a test failure... just terrible.
    This is a test failure at the core, because a version of a module down
    the chain wasn't tested.

    This is what CPAN Testers, in part, is designed to catch. Saying
    "they can't install a CPAN module" is an insult to the CPAN Testers
    effort and all the toolchain authors, too. There is a reason this
    stuff exists, it is so that CPAN modules are widely accessible.

    Welcome to the perl echo chamber...
    Hey, just because Jrockway is a emo who hates popularity doesn't mean we
    (the catalyst developers) don't care about installation failures. Matt has
    spent a lot of energy to make sure our dependency graph installs cleanly,
    for instance. And this issue has in fact already been resolved by the Mouse
    people, hasn't it?
    Marcus
    My point with the "welcome" was that I view Catalyst as (somewhat)
    outside of that echo chamber. If ever so slightly.

    The projects that care about release engineering help get out of the
    echo chamber, and there needs to be more of them. The EPO helps this,
    IMO.

    Moose (and Mouse), Catalyst, DBIx::Class all are good examples of
    release practices, in my opinion. Certainly not flawless, but it's
    getting there.

    And not to dilute credit, like you said, Matt does a fantastic job and
    deserves most the credit in the Catalyst + DBIC realm. Regardless of
    his perception, he is likely one of the best new user advocates
    around.

    Welcome ot the circle-jerk chamber...

    -J
  • Tomas Doran at Dec 1, 2008 at 5:39 pm

    On 1 Dec 2008, at 09:05, Marcus Ramberg wrote:
    And this issue has in fact already been resolved by the Mouse
    people, hasn't it?
    Yes. Or it will be once 0.12 is released.

    http://rt.cpan.org/Public/Bug/Display.html?idA254

    Cheers
    t0m
  • Mailing lists at Dec 1, 2008 at 9:00 am

    On Sun, 30 Nov 2008 18:10:22 -0600, Jonathan Rockway wrote:
    * On Sun, Nov 30 2008, Toby Corkindale wrote:
    If the automated install fails, people are likely to say "bah, this
    Perl thing sucks, let's go for that similar app written in
    PHP/Java/Ruby instead - at least it's simple to install!"
    Why do you care about what other people do? If these people can't even
    install a CPAN module, it's unlikely that they were going to become
    active contributors.
    I am absolutely stunned by this inappropriate and arrogant answer! Did you
    smoke your last couple of lisp scripts, man?

    Perl's future depends on those "other people", but that's a truth a lot of
    people in the Perl community haven't realized yet...

    --Tobias
  • Aristotle Pagaltzis at Dec 1, 2008 at 4:01 pm

    * Jonathan Rockway [2008-12-01 01:15]:
    Why do you care about what other people do?
    When I write software I generally hope others will find it
    useful. (Sometimes I write it purely for my own itches, but then
    it tends to be half-arsed in all sorts of ways because it doesn?t
    have to work for anything other than exactly the use cases I need
    it for.)
    If these people can't even install a CPAN module, it's unlikely
    that they were going to become active contributors.
    How many kernel drivers did you debug today?


    * Marcus Ramberg [2008-12-01 10:10]:
    Matt has spent a lot of energy to make sure our dependency
    graph installs cleanly, for instance. And this issue has in
    fact already been resolved by the Mouse people, hasn't it?
    It?s true. But the fact that the Mouse people had to fix this is
    an indication that a pretty high level of ongoing effort is
    necessary, which I see as a symptom of there being a fundamental
    problem.

    That doesn?t mean the alternative is better.

    I have no answers, unfortunately, only questions.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Jay Shirley at Dec 1, 2008 at 4:22 pm

    On Mon, Dec 1, 2008 at 8:01 AM, Aristotle Pagaltzis wrote:
    * Jonathan Rockway [2008-12-01 01:15]:
    Why do you care about what other people do?
    When I write software I generally hope others will find it
    useful. (Sometimes I write it purely for my own itches, but then
    it tends to be half-arsed in all sorts of ways because it doesn't
    have to work for anything other than exactly the use cases I need
    it for.)
    If these people can't even install a CPAN module, it's unlikely
    that they were going to become active contributors.
    How many kernel drivers did you debug today?


    * Marcus Ramberg [2008-12-01 10:10]:
    Matt has spent a lot of energy to make sure our dependency
    graph installs cleanly, for instance. And this issue has in
    fact already been resolved by the Mouse people, hasn't it?
    It's true. But the fact that the Mouse people had to fix this is
    an indication that a pretty high level of ongoing effort is
    necessary, which I see as a symptom of there being a fundamental
    problem.

    That doesn't mean the alternative is better.

    I have no answers, unfortunately, only questions.
    We just need to finish B::Perfect, then all our problems are solved.

    Software always will have glitches. Some people are tolerant, others
    are not. CPAN Testers is a great resource that helps identify
    potential problems, and some people are proactive about fixing them.
    I'm certainly not, though I should be.

    -J
  • Aristotle Pagaltzis at Dec 2, 2008 at 2:17 am

    * J. Shirley [2008-12-01 17:25]:
    Software always will have glitches.
    Exactly.

    Think about it. :-)

    (I tried to actually explain it, but after starting from scratch
    several times and getting more than a paragraph each time, I gave
    up. I don?t currently seem able to argue my point clearly and
    usefully. Oh well.)

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Marcus Ramberg at Nov 27, 2008 at 10:55 am

    On Thu, Nov 27, 2008 at 1:47 AM, Toby Corkindale wrote:

    Hi guys,
    I'm having trouble getting Catalyst to install (via CPAN) on a fresh Debian
    Etch install.
    The problem is the dependency Mouse (0.11) fails its unit tests there.
    (I'd guess due to the older versions of some core packages).

    I've raised http://rt.cpan.org/Ticket/Display.html?id=41254.

    Catalyst::Action::RenderView (first module which was wanting Mouse) itself
    seems to pass its own unit tests after Mouse is force-installed, though.
    Hey toby...

    http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL-
    I'm pretty sure RenderView does not depend on Mouse.

    Marcus
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20081127/62356602/attachment.htm
  • Simon Elliott at Nov 27, 2008 at 11:40 am

    Hey toby...

    http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL
    - I'm pretty sure RenderView does not depend on Mouse.
    is does however depend on Data::Visitor which uses Squirrel, so
    installing Moose should solve this.

    Simon
  • Tomas Doran at Nov 27, 2008 at 12:42 pm

    On 27 Nov 2008, at 11:40, Simon Elliott wrote:


    Hey toby...

    http://search.cpan.org/src/MRAMBERG/Catalyst-Action-
    RenderView-0.08/Makefile.PL - I'm pretty sure RenderView does not
    depend on Mouse.
    is does however depend on Data::Visitor which uses Squirrel, so
    installing Moose should solve this.
    No, because Squirrel is part of the Mouse package, and therefore
    won't help solve test fails in Mouse..

    Cheers
    t0m
  • Toby Corkindale at Nov 27, 2008 at 11:38 pm

    Simon Elliott wrote:

    Hey toby...

    http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL -
    I'm pretty sure RenderView does not depend on Mouse.
    is does however depend on Data::Visitor which uses Squirrel, so
    installing Moose should solve this.
    Squirrel is bundled in the Mouse package.
    Mouse fails to install cleanly.
    ..
    One can force the install, but I remember MST asking for reports of
    instances where Catalyst didn't install cleanly, and this is one of
    those cases.

    ta,
    Toby

    --
    Strategic Data Pty Ltd
    Ph: 03 9340 9000
  • Toby Corkindale at Nov 27, 2008 at 11:35 pm

    Marcus Ramberg wrote:
    On Thu, Nov 27, 2008 at 1:47 AM, Toby Corkindale
    wrote:

    Hi guys,
    I'm having trouble getting Catalyst to install (via CPAN) on a fresh
    Debian Etch install.
    The problem is the dependency Mouse (0.11) fails its unit tests there.
    (I'd guess due to the older versions of some core packages).

    I've raised http://rt.cpan.org/Ticket/Display.html?idA254.

    Catalyst::Action::RenderView (first module which was wanting Mouse)
    itself seems to pass its own unit tests after Mouse is
    force-installed, though.


    Hey toby...

    http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL
    - I'm pretty sure RenderView does not depend on Mouse.
    Hi Marcus,
    C-A-RV depends on Data::Visitor, which depends upon Mouse.

    I'm sure it's not the only Catalyst module which depends upon
    Data::Visitor though?

    Toby


    --
    Strategic Data Pty Ltd
    Ph: 03 9340 9000
  • Toby Corkindale at Nov 27, 2008 at 11:43 pm

    Toby Corkindale wrote:
    Hi guys,
    I'm having trouble getting Catalyst to install (via CPAN) on a fresh
    Debian Etch install.
    The problem is the dependency Mouse (0.11) fails its unit tests there.
    (I'd guess due to the older versions of some core packages).

    I've raised http://rt.cpan.org/Ticket/Display.html?idA254.
    .. and after a speedy reaction from the maintainer of Mouse, the problem
    has been traced to Test::Exception.
    It seems the (as usual, ancient) version shipped with Debian "stable" is
    broken in some respect to handling the magic that goes on inside our
    four-legged squeaky friend.

    Upgrading Test::Exception from 0.21 to 0.27 resulted in Mouse passing
    all tests.

    Toby

    --
    Strategic Data Pty Ltd
    Ph: 03 9340 9000
  • Peter Edwards at Dec 1, 2008 at 10:05 am

    While Data::Visitor depends on Mouse, it actually uses Squirrel (which
    is in the Mouse dist), which will fall back to the Moose already loaded
    by Catalyst. I assume most Mouse-users are smart enough to do this.
    It's a menagerie of woe!

    Why not add some deps for Wombat and Echidna depending on
    Mammal::Oviparous too
    ;-)

    Regards, Peter
    http://perl.dragonstaff.co.uk

Related Discussions

People

Translate

site design / logo © 2022 Grokbase