in reply to RFC: Private CPAN In A Box

How would teams use it to distribute and share their own modules and applications within the organization?
I wouldn't have it based on CPAN. For code written inside the organisation, I'd use a source control system. Deployment, I'd either distribute using the source control system, or a package system that's appropriate for the OS (for instance, rpms + yum + cfengine) and the organization. And I'd use the same package system to distribute external packages.

Frankly, I wouldn't know what to use a "private CPAN" for. What's the point, and why would an organization want to limit itself to a system that's geared to a single language, and is designed to do quite different things than corporations need?

Replies are listed 'Best First'.
Re^2: RFC: Private CPAN In A Box
by jthalhammer (Friar) on May 21, 2011 at 07:47 UTC

    I wouldn't have it based on CPAN. For code written inside the organisation, I'd use a source control system. Deployment, I'd either distribute using the source control system, or a package system that's appropriate for the OS

    A private CPAN does not preclude you from using a source control systems for deployment. Nor does it preclude you from using a more general packaging system (like RPMs) to distribute your code. These are complimentary technologies that fit around a private CPAN.

    What's the point, and why would an organization want to limit itself to a system that's geared to a single language, and is designed to do quite different things than corporations need?

    In my experience, the purpose of a private CPAN is to enable organizations to leverage the CPAN tool chain for managing the dependencies between their own modules and their third-party libraries (i.e. the public CPAN).

    I'm not suggesting that everyone *should* use a private CPAN, especially if they are already comfortable with their dependency management infrastructure. However, there are a significant number of organizations that don't manage their Perl module dependencies well. Often times, this leads to application failures, unnecessary development costs, and general chaos.

    Private CPANs have started to emerge as one possible solution for managing Perl module dependencies. But the current tools for creating, maintaining, and using a private CPANs are very fragmented. Moreover, the patterns for using those tools are not well established. My goal is to assimilate the existing tools and knowledge (and perhaps some new tools and knowledge) into a coherent product.

    So this thread certainly isn't relevant for everyone. But if your production system has ever crashed because the team down the hall decided to upgrade their app to the latest Catalyst, or if you have to debug in production because you can't reproduce the exact same system somewhere else, or if you've ever had to force-install a module with failed tests, then I want to hear from you.

    Jeffrey Thalhammer
    Imaginative Software Systems

[reply]
      In my experience, the purpose of a private CPAN is to enable organizations to leverage the CPAN tool chain for managing the dependencies between their own modules and their third-party libraries (i.e. the public CPAN).
      But the CPAN toolchain is actually really bad in managing dependencies. Sure, it allows the author to signal a dependency on another CPAN module, but it isn't very suited to do dependencies on non-CPAN modules. OS package systems (including those ported to a range of OSses, like RPM) and distributions systems like cfengine (which allows specifying dependencies based on the role of a box) far superior for that task that CPAN.
      Nor does it preclude you from using a more general packaging system (like RPMs) to distribute your code. These are complimentary technologies that fit around a private CPAN.
      Pray tell me, if I'm already using RPMs, what additional value does a private CPAN give me?
[reply]

In Section Meditations