On May 20, 2011, at 3:51 AM, Jeffrey Thalhammer wrote: > Once again, I'm faced with building another private CPAN. But this time, I > have an opportunity to build something that could have broader appeal in the > Perl community. In fact, the explicit goal is to produce an open source, > turnkey framework for creating, deploying, and maintaining a private CPAN.
FWIW, I've written one, called PGXN. The various parts are managed here: https://github.com/pgxn/ PGXN::Manager == PAUSE PGXN::API && PGXN::Site == search.cpan.org pgxnclient = CPAN.pm The client was actually written by someone else, in Python, just using the API. https://github.com/dvarrazzo/pgxnclient/ He was able to do it pretty quickly because almost everything is represented by a static JSON file. The mirror and API APIs are documented here: https://github.com/pgxn/pgxn-api/wiki Might be of interest to you, FWIW. I wrote it for PostgreSQL Extensions, but tried to implement a generalized solution that could be used by any language or community -- or privately, if you like. > So with that in mind, I'm looking for feedback on what you might want from > such a framework. Here are some questions I've been asking myself -- > hopefully they will help stir your mind: > > How would it provide an identifiable & reproducible stack of dependencies > that developers can use to write, test, and deploy their code against? Do you mean dependencies to build the framework itself, or how to identify dependencies in distributions released to the network? META.json works great for both of these, IMHO. > How would it allow one to define and deliver a standardized set of > dependencies to all your environments? Not sure I understand the question here… > How would it enable developers to experiment with dependencies that are not > part of the standard environment? What is "the standard environment"? > How would it enable different teams to work against different versions of > their dependencies? You mean other than just preserving earlier versions of distributions? > How would it enable teams to independently upgrade, add, and remove their > dependencies in a controlled, reproducible manner? I think your use of the term "dependencies" confuses me. What are "dependencies"? > How would teams use it to distribute and share their own modules and > applications within the organization? I don't understand. You upload your module or app to the upload server. > Which parts of the larger CPAN ecosystem would be most valuable in a private > CPAN (e.g. CPAN Testers, AnnoCPAN, search.cpan.org, CPAN Ratings)? That's really going to depend on the requirements of the organization, I would think. Some will think testing is important; others that ratings or wikis are important. > How would one migrate their legacy code into CPAN-style distributions? Fortunately, all one needs to do is add a META.json file and you're read to go. Unless you want a single method of installing distributions, in which case you would either need to build an installation client that recognizes and executes many different approaches to building, or get your users to adopt one. > How would one migrate from their existing dependency management > infrastructure to a private CPAN? Again, just define dependencies in the META.json file. > How might one want incorporate a private CPAN with their other development > infrastructure, such as bug trackers & continuous integration servers? Provide a robust API. :-) > Thanks for sharing your thoughts! HTH, sorry I get a bit lost with some of your questions. Best, David
