http://qs321.pair.com?node_id=11116544


in reply to Setting up and accessing a DarkPAN

I set up a Darkpan recently. It was intended only to provide some internal modules, making them available for installation using standard CPAN tooling. I didn't need presentation, so my webserver is just minimal Mojolicious::Lite app that serves the tarballs in a CPAN-style file hierarchy as static content. To build the Darkpan I used CPAN::Mirror::Tiny. It works just fine.

This solution doesn't provide a web GUI, just the barebones file structure needed by CPAN tools like cpan and cpanm. The latter is what our consumers mostly use, via Carton.

We build our distributions into a Darkpan prototype on a build server, and then rsync the files that got modified with new versions over to a mirror that has both Beta and Production level Darkpan mirrors on it. We don't delete old versions; we keep them around so that consumers can pin to a version, and so that consumers can roll back as needed.


Dave

Replies are listed 'Best First'.
Re^2: Setting up and accessing a DarkPAN
by kcott (Archbishop) on May 08, 2020 at 02:52 UTC

    G'day Dave,

    Thanks for the information. Along with the ability to use tools like cpan and friends, a web GUI with functions including search facilities and a POD viewer will be required.

    I had a look at CPAN::Mirror::Tiny. Its "WHY NEW?" section appears to promote its "no dependency on XS modules" as one of the main reasons to use it. There are no ($work) issues with XS modules; in fact, they would generally be preferred over pure Perl equivalents for the speed improvement.

    — Ken

[reply]

      That makes sense. My use-case simply didn't involve GUI browsing. It's pretty easy to read the 02 index file either way. What I found CPAN::Mirror::Tiny to be useful for, was in taking distribution tarballs, using them to build the required file structure and index file, which is the bare essentials of a Darkpan.

      I suspect if I wanted browsability, I would probably still use CPAN::Mirror::Tiny to build my darkpan, and then use a different module as the business end of a web GUI. I don't see this module as excluding the use of a GUI-providing module. But it is entirely possible there's a more suitable alternative for your needs.

      Incidentally, I actually intend to talk about building a Darkpan at the online / virtual version of the Perl Conference this year. But my talk will spend some of its time on how to convert internal use modules into distributions that are suitable for an internal darkpan, and the strategies we used for building and shipping to the mirror. I hadn't intended to get into anything regarding a front end GUI.


      Dave

[reply]
        "I actually intend to talk about building a Darkpan at the online / virtual version of the Perl Conference this year."

        That sounds like something that would interest me. Assuming there's a recording of this, could you post a link when such is available.

        — Ken

[reply]

In Section Seekers of Perl Wisdom