Changes between Version 1 and Version 2 of ModuleEcosystem

Show
Ignore:
Timestamp:
08/12/09 23:25:59 (5 years ago)
Author:
japhb
Comment:

Incorporate Allison's first review email notes; visual tweaks

Legend:

Unmodified
Added
Removed
Modified
  • ModuleEcosystem

    v1 v2  
    1919     build and manage a module distribution network ... 
    2020   * However it should be possible for another group to do so. 
     21     * It is unlikely someone will try to mirror the entire history 
     22       of every dynamic language module ever made, 
     23     * But for instance serving torrents of Power Packs seems reasonable. 
     24   * The search API and install process be dead simple and clearly specified. 
     25     * Clone implementations used by other ecosystems will be a mark of success. 
    2126 * Toolchain 
    2227   * Basic tools can assume Parrot and the core modules are working, 
     
    4146     wiki, homepage, source repository, etc. 
    4247   * Allows disambiguation as per Perl 6 module spec (authorities, 
    43      versions, authors, etc.). 
     48     versions, authors, etc.), as well as equivalents for PHP PEAR, 
     49     RubyGems, Python Eggs, etc. 
    4450   * Specifies rules for dependency string parsing/interpretation. 
    4551 
     
    4753= Proposal = 
    4854 
    49 ''''' This is a rough draft!  Suggestions welcome! ''''' 
     55''''' This is a rough draft; suggestions welcome! ''''' 
    5056 
    5157 * Overview 
     
    6167     growth of the ecosystem until it stands on its own. 
    6268 * Metadata format 
    63    * Served metadata container is gzip'ed tarball (.tar.gz? .tgz?). 
    64    * Core metadata is in META.json at top level of container. 
    65    * Container includes copies of special files (e.g. README). 
     69   * Metadata served as JSON. 
    6670   * Format for specifying non-metadata-only build scripts undecided. 
    6771   * Integrity check / authentication methods undecided. 
    68      * Probably at least md5sum and sha1sum for source tarballs, 
    69        but what about when pulling from raw VCS repo? 
     72     * ''Probably at least md5sum and sha1sum for source tarballs, 
     73       but what about when pulling from raw VCS repo?'' 
     74 * Metadata server API & UI 
     75   * Web form UI 
     76     * Enter/update/remove all module information (metadata fields) 
     77     * Deprecation/EOL 
     78     * Accept raw JSON block as alternative 
     79   * Simple HTTP/JSON API 
    7080 * Core modules 
    71    * parrot config  (already exists -- config.pir) 
     81   * parrot config  (already exists -- `config.pir`) 
    7282   * HTTP client    (at least GET, with redirect and proxy support) 
    7383   * zlib           (at least decompress) 
     
    7686   * version spec   (at least parse and compare) 
    7787   * library probe  (shared library info: present? version? location?) 
    78    * file paths     (portability: File::Spec + File::Basename + ...)  
     88   * file paths     (portability: `File::Spec` + `File::Basename` + ...)  
    7989   * file install   (portability: copy file, set file perms, etc.) 
    8090   * query metadata (perform API calls to metadata/search server) 
    8191   * installer lib  (all the real brains/glue for the module repo client) 
    82    * installer ui   (CLI and/or Readline, minimal brains, uses lib) 
     92   * installer ui   (CLI and/or `Readline`, minimal brains, uses lib) 
    8393 * Basic Batteries modules 
     94   * ''Note: Basic Batteries is just another Power Pack from a technical viewpoint; it is merely treated slightly differently in the community.'' 
    8495   * Full versions of any modules that are limited in Core 
    8596   * Installer add-ons:   VCS fetch/use system pkgs/full depresolve/etc. 
    86    * Module author tools: create/register/update/upload/etc. 
     97   * Module author tools: easy create (module or pack)/register/update/upload/etc. 
    8798   * PIR-level tools:     disassembler/debugger/profiler/data dumper 
    8899   * NCI tools:           parse header/manage typemap/wrap C struct/etc. 
    89    * Standard interfaces: TAP, DBDI, logging, ? 
    90    * Standard libraries:  OpenSSL, DateTime, temp dir/file, ? 
    91  
     100   * Standard interfaces: `TAP`, `DBDI`, logging, ? 
     101   * Standard libraries:  `OpenSSL`, `DateTime`, temp dir/file, ? 
    92102 * Possible Power Packs (NOTE: '''EXAMPLES ONLY''', DON'T BIKESHED!) 
    93103   * Database:     DBDs (drivers), SQL clients, per-HLL DBI variants 
     
    103113   * Sound:        OpenAL, Pulse Audio, JACK, ... 
    104114   * Game Support: Require other Power Packs: Audio, 2D/3D Graphics 
    105  
    106115 * Misc recommendations 
    107    * Separate 'parrot-modules' mailing list for module creators/users 
    108      only if parrot-dev traffic gets overwhelmed. 
     116   * Separate `parrot-modules` mailing list for module creators/users 
     117     only if `parrot-dev` traffic gets overwhelmed. 
    109118   * Default to simple (CPAN-style) dependency resolution; upgrade to 
    110119     full resolution and system package awareness in Basic Batteries. 
     120   * Master metadata site will be `reponame.parrot.org` 
    111121   * Names so far suggested for module repository network: 
    112122     * Bird Words 
     
    116126       * Plumage 
    117127       * Roost 
    118      * Acronyms 
     128     * Acronyms ''(generally disliked, and leads to CPAN comparison/expectation)'' 
    119129       * CPAAN 
    120130       * FPAN 
     
    130140   * version 
    131141   * license 
    132      * type 
     142     * type ''(standard short names for common licenses)'' 
    133143     * uri 
    134144   * copyright_holder 
    135145   * abstract 
    136  * Manifest fields: 
     146   * instructions 
     147     * type ''(standard names for common build sequences, 
     148       such as `cpan-mm` for CPAN + `ExtUtils::MakeMaker`, 
     149       or `custom` for custom instructions)'' 
     150     * fetch 
     151     * configure 
     152     * build 
     153     * test 
     154     * install 
     155     * runtime ''(here for completeness; necessary?)'' 
     156 * Manifest fields ''(still under discussion; for scriptless installs)'': 
    137157   * files 
    138158     * configure 
     
    145165       * lib 
    146166       * runtime 
    147  * Dependency fields (as { [dep_name]: [version_spec], ... }): 
     167 * Dependency fields (as { [''dep_name'']: [''version_spec''], ... }): 
    148168   * provides 
    149169   * conflicts 
     
    157177 * Optional features fields: 
    158178   * optional_features 
    159      * [feature_name] 
     179     * [''feature_name''] 
    160180       * description 
    161        * [any/all dependency fields as needed] 
     181       * [''any/all dependency fields as needed''] 
    162182 * Other optional fields: 
    163183   * description 
     
    181201       * project_uri 
    182202     * mailinglists 
    183        * [list_name] 
     203       * [''list_name''] 
    184204         * address 
    185205         * uri 
    186206 * Undecided fields: 
     207   * ''How do fields get added to spec?  Allow custom fields?'' 
    187208   * dynamic_config 
    188209   * no_index