Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jk2addict (4946)

jk2addict
  (email not shown publicly)
http://today.icantfocus.com/blog/
AOL IM: chrislaco (Add Buddy, Send Message)
Yahoo! ID: chrislaco@sbcglobal.net (Add User, Send Message)
Jabber: laco@scribblewerks.com

Journal of jk2addict (4946)

Wednesday July 25, 2007
12:04 PM

How do deal with circular dists in PREREQ?

[ #33884 ]

What's the most sane approach to circular dist dependencies when using things like Module::Install 'features'?

I just moved Handel to use M::I last night, and added H::Storage::RDBO as an optional feature. Of course, the H::Storage::RDBO dist has Handel a a prereq. Now I have a nice lovely circular dependency.

What's the common practice on dealing with this issue? Do I just remove Handel from the prereqs listead in H::S::RDBOs Makefile? ...and make all tests skip, or die? How will automated testers know what to do, or how do you cope with all of the failing reports when servers just try testing H::S::RDBO on their own?

Can't say that I've ever had to tackle this before. :-/


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

How do deal with circular dists in PREREQ? 6 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If the only time you can list something in PREREQ_PM is if it is already installed, you lose. Just have your tests skip the optional parts.

    Or merge the two dists so they come simultaneously.
    • To me, this is really a toolchain failure.

      If something is an 'optional feature', it needs to be treated like 'install this afterwords' rather than 'this is a prereq'...because, it isn't a prereq.

      • It is a toolchain issue alright, but installing “optional feature” modules afterwards would be a mistake, because then the tests for them would never get run. Rather, what you want is for the toolchain to be able to figure out that when distro A recommends distro B and distro B depends on distro A, then distro B can be installed afterwards. Whereas if distro A recommends distro B but distro B does not depend – directly or indirectly – depend on distro A, then distro B needs to be ins

        • "modules afterwards would be a mistake, because then the tests for them would never get run"

          I'm not sure that's always true either. The tests for the optional additional 'features' are in that features dists, not the original dist. NO reason they won't be run.

          Definitely seems like a disconnect on some level. Maybe if the code wasn't actually named 'feature' I wouldn't care so much. :-)

          • No, that’s not what I meant. If distro A has an optional feature that requires distro B, then installing B after A means that A’s tests for the optional feature will never be run.

  • This is actually a non-issue*, which CPANPLUS handles gracefully for your. Try it ;)

    The trick is to detect the circular dependency and take the appropriate action.
    In CPANPLUS' case, we add the path to one module's extract dir to @INC, then build & install the other, reset @INC, then build the first.

    * Where 'non-issue' holds true if at least 1 of the 2 dependencies is pure perl

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.