TODO

### Looking for something to work on? See TASKS.
###
### This file is more of a "don't forget to do this" list.


Study:
------
* CPAN META/MYMETA changes afoot
* proto changes afoot
* Haskell Cabal (http://www.haskell.org/cabal/)
* LuaRocks (http://www.luarocks.org/en/luarocks)
* Ruby Rake (http://rake.rubyforge.org/)
* Possibly useful modules
  * ExtUtils::Liblist
  * Devel::CheckLib
  * Devel::CheckOS (relatively standard list of OS names?)
  * Software::License (standard list of FOSS licenses, with templated text)
* Debian & Fedora version numbering specs
* Debian & Fedora dependency/relationship specs
  * http://www.debian.org/doc/debian-policy/ch-relationships.html
* HLL version numbering specs
  * At least JS, Perl 5, Perl 6, PHP, Python, Ruby, Tcl


Metadata:
---------
* Separate spec in terms of data structures v. serialization format?
* Formalize experimental metadata 'namespace'
  * Ignored by validators (except still syntactically valid JSON)
  * Ignored by clients that don't recognize them
  * Guaranteed never to clash with future official metadata
  * Keys beginning with x- or X-
* Define recognized version number strings, and how to compare them
  * Including wildcards, subsets, and ranges
  * Define mappings from native edge cases to canonical?
* Platform dependent:
  * Instructions?
  * Dependencies?
  * CPAN meta spec trying to avoid this (or at least delay to spec 3.0)
* Collect all phase-specific metadata into one deeper tree?
  * CPAN metadata spec likely to go this route
* Error conditions
  * Everything currently implemented in Plumage::Metadata
  * 'update' instructions without 'fetch'
* general
  * Easy way to reference CREDITS file in contributors key?
  * Repo fetches from tip have version 'HEAD'
  * List of known licenses
    * Specials: Open_Source, Restrictive, Unrestricted, Unknown
    * Multiple licenses allowed -- but *NO* details about what this means
    * See lines 179-231 of
      http://github.com/dagolden/cpan-meta-spec/blob/17-license/META-spec.pod
  * Copyrights
    * May be multiple copyright holders
    * http://dep.debian.net/deps/dep5/
  * Status
    * Stable/testing/unstable?
* instructions
  * 'fetch' of a repository should have 'repository' as its type
  * 'type's must have underscores, not hyphens
  * 'patch' phase
  * Types of 'test'?  basic, spec, extra, author, ...?
  * Phase(s) for release (to CPAN, as RPM, ...)?
  * Special case of configure type for accepting --parrot-config option?
  * What about update and cleanup?
  * What about multiple instructions per key?
    * Allow value to be either hash or array of hashes?
* dependency-info
  * 'provides' is always an array
  * HLLs provide their project name and their language name
  * 'development_requires'?
* resources
  * feed_type and feed_uri for hosting that provides Atom/RSS commit feeds
  * branch
  * module (CVS)
  * user/pass (if not default for anonymous use)
  * commit/rev spec
  * multiple possible repos?
  * bug_tracker
    * type
    * home page uri
    * submit uri
    * submit email
  * contacts
    * general
    * legal
    * security
    * array-valued?


Plumage:
--------
* Switch to setup.nqp once NQP-rx supports native hash declarations
* Hosting:
  * allison looking into parrot.org
  * moritz gave access to a Debian Lenny box
* UIs:
  * Interactive mode
* Functionality:
  * Read meta from repo after fetch/patch/configure
  * System and local installs
    * Where should local installs go by default?
    * How to make parrot aware of local install path?
  * Arch-specific and non-specific install dirs?
  * Platform hints
    * config items not provided by parrot, like PATH separator
    * binary renames
    * handle needing to HOMEDRIVE ~ HOME on Win32
  * Official metadata spec validator tool (module?), with test suite
  * Use Plumage's Configure.nqp and test harness for project config/test
  * Anything proto can do, and more
    * Meaningful exit codes
    * Quiet modes: Log, Silent, Verbose
      * If progress bars, use N * Width / (N + Width) to determine length
      * Interaction with sudo?
      * Other prompts?
    * Create new project helper
    * 'showstate' command (show build and install status) (WIP)
    * 'wipeout' or 'purge' command -- uninstall and uncache
    * 'fetch' able to do owner-clone for git repos
      * User able to specify list of authorities they have commitbits for?
    * 'configure' able to run any of:
      * Makefile.PL
      * Configure.pl
      * Configure.p6
      * Configure
    * 'test' action using (recursive) 'prove' directly
    * 'all' pseudo-project
      * 'install all' is probably scaling out of reasonable range now
      * But 'update all' is reasonable
    * Make source tarball and native packages
* Spec:
  * Add Stakeholders section
  * Add Usage Scenarios section
  * Author v. User dynamic dependency differences (aka META v. MYMETA)
  * DSLIP info in META?
  * Interoperate with pkg-config and/or ExtUtils::Liblist?
    * Use them to find system libs?  Or use their *algorithms* to do so?
      * #toolchain considered writing a Pure Perl pkg-config workalike
      * ExtUtils::PkgConfig exists ...
    * Generate .pc files if module install type does not automatically do so
    * Hmmm, seems to be some fail here WRT standardizing lib names ...
* Documentation
  * Add a tutorial/examples document
  * FAQ
    * Relationship between plumage and distutils/make/etc.
* Test Suite
  * Figure out how to mock svn/git repos so that build/fetch/test/configure
    steps can be tested
  * Check exit code of each test file
  * Massively expand tests
  * Improve harness output
* Misc suggestions
  * Merge Plumage .pbc's all together into executable using pbc_merge
  * Avoid asking questions (after first setup?) if at all possible
  * Recommendations ("optional dependencies") should not abort top-level
    install if they fail to install
  * rake madness (from Cardinal):
    * PARROT_CONFIG={{parrot_dir whatever}}/parrot_config rake cardinal
    * rake test:all
* Suggestions from proto-ng team
  * $PREFIX defaults to $HOME/.ecosystem/lib
  * Rakudo doing:
    * [builtins/globals.pir] preload $HOME/.perl6lib and languages/perl6/lib in @*INC
    * $HOME/.perl6/lib + $HOME/.perl6/proto/config ?
    * parrot_install/bin + parrot_install/lib/1.5.0-devel/languages/perl6/
    * From #perl6:
      * mberends does not like adding directories to PATH
        mberends does 'sudo ln -s <parrot_install>/bin/perl6 /usr/local/bin' instead
* Rename --ignore-fail=<stage>=0 to --no-ignore-fail=<stage> as this is a more common
  convention and is much cleaner


CLI:
----
* Support temporary and permanent modification of config file
* Fully document usage in docs/interactive.pod
* Display Plumage version in welcome message (update example in docs/interactive.pod)


Misc:
-----
* Move all perldoc to top of file so code is easier to read
* Improve output messages so that they don't try to sound like a real person talking
  because this is really childish.
* Reword all comments that say Plumage is the "module ecosystem" because that's not
  true: it's a package manager for the module ecosystem
* Cleanup code for probe tests


Parrot:
-------
* Fixes needed:
  * More secure pipe spawn
    * current insecure version does 'sh', '-c', 'command and args'
* Config values needed:
  * PATH separator
* Finish JSON -> data_json conversion
  * Change tests to use data_json language
  * Deprecate JSON language


NQP:
----
* See http://wiki.github.com/perl6/nqp-rx/requests


data_json:
----------
* Less pedantic parse
  * Allow trailing comma in array and hash
  * Allow unquoted keys
* Better error messages!