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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This is very, very shiny. Thank you.

    How are you planning to deal with the fact that different repositories have different semantics for describing dependencies? (For example, not all CPAN modules make the distinction between dependencies needed at install time and runtime).

    What assumptions are you making about a CPAN module distribution? (I started an effort to try to document exactly how a distribution was made up, but had to leave it for other things a few months ago, looks like I should start working on
    • > How are you planning to deal with the fact that different repositories
      > have different semantics for describing dependencies? (For example, not
      > all CPAN modules make the distinction between dependencies needed at
      > install time and runtime).

      Some of this is still unsolved.

      Currently I think there will probably be built-in vocabulary for dependencies that covers 5 phases (config, build, test, install, runtime) and some concept of a resource with various subtypes (packages/distribution, class/interface, etc etc) and various version mapping (cpan's "equal or greater" or "only" etc).

      > What assumptions are you making about a CPAN module distribution?
      > (I started an effort to try to document exactly how a distribution
      > was made up, but had to leave it for other things a few months ago,
      > looks like I should start working on it again.)

      As few as possible at the moment. Andrea understands the process of developing a vocabulary better than I do.

      > What assumptions are you making about a module's build system?

      For the moment we are assuming that for a single source package, you follow the following steps.

      1. Configure
      2. Build
      3. Test
      4. Install

      This seems to be fairly consist across most languages.

      > How are you planning to deal with module tests?

      We plan to run them :)

      More specifically, they aren't likely to be refered to in the grammar, as they aren't relevant beyond any test-time dependencies.

      > Do you have a website/mailing list/hive mind where you're
      > coordinating all of this?

      Nope. This is very very early days at the moment, and I plan to move slowly.

      There is however some half-finished doodlings sitting at

      http://svn.phase-n.com/svn/cpan/trunk/PIG/ [phase-n.com]

      And there's probably some digital camera shots of whiteboards around somewhere.

      I don't plan to put too high a priority on this project for now, as it's about 90% interpersonal communication and not really much to do with coding. And projects that involve communication tend to take a while.

      I'd expect this to take in the 2-3 year range to get to a sufficiently acceptable 1.0 release of the grammar (assuming the concept holds).