Changes between Version 2 and Version 3 of ModuleEcosystem

Show
Ignore:
Timestamp:
08/12/09 23:52:06 (12 years ago)
Author:
japhb
Comment:

More edits from emails

Legend:

Unmodified
Added
Removed
Modified
  • ModuleEcosystem

    v2 v3  
    3232   * Tools should attempt to auto-configure as much as possible. 
    3333   * Tools must properly handle the difference between user-local, 
    34      site-local, and vendor-installed modules. 
     34     site-local, and vendor-installed modules.  ''(Do we need these 
     35     particular cases?  Why not just support arbitrary custom paths?)'' 
    3536 * Metadata 
    3637   * Simple, extensible format. 
     
    3839   * Must include its own spec version. 
    3940   * Sufficient for automated programs to create system packages 
    40      (DEB, RPM, etc.). 
     41     (DEB, RPM, etc.). ''(We may be only able to handle the common 
     42     cases and provide guidance on the harder ones.  However, having 
     43     this as a goal should help us shake out weak points in the spec.)'' 
    4144   * Separate static v. configure-discovered v. hand-edited metadata. 
    42      Separate files? 
     45     Separate files? ''(Overly complex?  Needs followup with `#toolchain`.)'' 
    4346   * Includes fetch, configure, build, test, install, and runtime 
    4447     dependencies. 
     
    7376       but what about when pulling from raw VCS repo?'' 
    7477 * Metadata server API & UI 
     78   * ''Some disagreement on details, but general agreement to:'' 
     79     * ''Minimize effort for module authors and end users,'' 
     80     * ''But get something simple working '''first'''.'' 
     81   * ''Note: The module author may '''not''' be the one using the UI; 
     82     this may be a packager or Parrot team member.'' 
    7583   * Web form UI 
    7684     * Enter/update/remove all module information (metadata fields) 
     
    7886     * Accept raw JSON block as alternative 
    7987   * Simple HTTP/JSON API 
     88     * ''Push or pull updates?'' 
    8089 * Core modules 
     90   * ''Note: These should be minimal, no extra fluff.'' 
    8191   * parrot config  (already exists -- `config.pir`) 
     92   * compiler tools (already exist -- PGE, PCT, NQP) 
    8293   * HTTP client    (at least GET, with redirect and proxy support) 
    8394   * zlib           (at least decompress) 
     
    101112   * Standard libraries:  `OpenSSL`, `DateTime`, temp dir/file, ? 
    102113 * Possible Power Packs (NOTE: '''EXAMPLES ONLY''', DON'T BIKESHED!) 
     114   * ''(There is some disagreement where Power Packs should lie on the standalone <-> dependency-laden spectrum.)'' 
    103115   * Database:     DBDs (drivers), SQL clients, per-HLL DBI variants 
    104116   * Testing:      smoke/tinder/smolder clients, per-HLL Test::* variants 
     
    118130   * Default to simple (CPAN-style) dependency resolution; upgrade to 
    119131     full resolution and system package awareness in Basic Batteries. 
     132     ''(OS packaging systems already had to solve all of this; let's 
     133     not go reinventing wheels.)'' 
    120134   * Master metadata site will be `reponame.parrot.org` 
    121135   * Names so far suggested for module repository network: 
     136     * For trademark purposes, may need to be 'Parrot Foo' rather than just 'Foo' alone. 
    122137     * Bird Words 
    123138       * Aviary