Simon Wistow (deflatermouse) wrote,
Simon Wistow

Reinventing CPAN

At work I'm reinventing CPAN but for a multitude of interoperating languages. Which sounds an awful lot like FreePAN which coincedentally seems to have got some momentum at YAPC::Taipei.

To be honest I don't like some of the design decisions of FreePAN, particularly the "being backed by Subversion" nature. I don't even like the idea that it's backed by a VCS let alone tying into one specific one. I just feel that there should be a distinction between developer, installer and user. But maybe I'm strange.

My current plan is to not try and parse meta data out of different formats which should be possible but would take too long. Instead all meta data gets stored in various files in the root directory - MANIFEST, MAINTAINERS, VERSION, DEPENDENCIES are the obvious ones. It mandates that there must be a docs directory with html docs in it. This is so hacky it's not even true but I can't think of another clean way of guaranteeing there being HTML documentation.

Some other design issues I've thought of :-

How to deal with Branching

Do we tag automatically on release, release automatically on tag or keep the two seperate?

Keeping VCS agnostic

What language to write it in - should (could?) the frontend and the indexer be written in different languages

Do we generate the distribution using MANIFEST and VERSION or should the user provide a generate_dist script?

Dummy packages (i.e external dependencies)

RPM etc. generation

Is there a smarter way of doing the DB design so that schema changes aren't a complete arse?

Tags: agnostic, arse, cpan, db design, design decisions, html, indexer, languages, manifest, meta data, root directory, subversion, tag, vcs

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.