CPAN and PoshCode vNext

I want CPAN for PowerShell

And I can't get it from PoshCode 2, because I need better support for modules. So I'm moving on without ever bothering to put it on the main site. Sorry.

Here are my core requirements (please feel free to comment in-line to add more):

• Support script-source modules and binary modules
• Support ownershipof modules. With single-script contributions we weren't very worried about this, but with modules we are.
• Track dependencies so we can tell you Module X needs Module Y
• Be able to easily download and install modules from the site
• Track versions (and be able to "upgrade" all your modules to the latest versions)
• Be able to search (and download) via the website and via an API (so I can write cmdlets, and custom hosts can write UIs around it).
• Specifically: be able to search and find a module that has a specific command in it
• Documentation (look at CPAN). We need to allow basic (searchable) module documentation, plus documentation per cmdlet/function, plus examples
• Simple. After all of that is implemented, we still need to support sharing of simple single-function scripts without forcing people to fill in tons of data!

Please take a moment and look at a few CPAN modules and compare them to Technet Script Gallery contributions.

Main Concepts:

• Ownership. I'm going to take a cue from CPAN on this and provide user pages, and have modules be located withing the user, ie: http://search.cpan.org/~adamk/ which has links to all of that user's modules, like http://search.cpan.org/~adamk/Archive-Zip-1.30/
• Documentation. Again, taking a cue from CPAN, I think we need documentation for modules.
  • Check out the page for Archive::Zip
    • Notice the sub-modules
    • Notice the META file? The license, website link, etc are parsed from that.
    • Notice the way previous versions are handled
  • Check out the main module page.
    • Notice how it's all documentation?
    • This root documentation is GENERATED from the README file
    • The submodules (notice only a couple are links?) have documentation generated from the module in-line docs.
  • Notice the extra documentation (FAQ, in this case) on this parent module page
  • Interestingly, if you want to submit documentation for someone else's module, you need to do so by sending it to them!
• Scripts. The requirements for submitting single-file scripts will be much simpler: basically, just categorize it and paste it in.
  • But they'll be listed slightly separately from modules (although ultimately, they have to be searchable all together).
  • Should I continue to allow anonymous uploads (marked as anonymous) or require login?
  • Should scripts be listed WITH modules (under the user's name), or should they be as separate as they are on CPAN? (cpan.org/scripts doesn't even show on search.cpan.org)
• Namespaces. Still debating this :)
  • CPAN serves as a global clearinghouse for naming, by virtue of serving as the global clearinghouse for modules...
  • With CPAN, although modules are listed under the user, other users are not allowed to have an alternate module with the same name (ie: Archive::Zip) because it would cause problems when you tried to install it. The same is true with PowerShell.
  • However, CPAN modules always seem to have a "namespace" ... thus, you can have the same functionality, and possibly even the same commands, as long as your module name is different (eg: IO::Compress:Zip or Backup::ZIP).
• Uploads. I think I like CPAN's model for this, too.
  • Handle module contributions by having the user upload a .zip (.tgz for CPAN).
  • Expect the zip to have a unique name like: Archive-Zip-1.26.tar.gz and ignore it if it doesn't.
  • Get the module version from the archive file name: x.xx or, for development releases: x.xx.xx
  • Extract a readme.markdown documentation file from the archive!
  • Extract additional documentation from comments in scripts/modules in the archive.
  • Display any extra files that have .txt or .markdown endings for viewing by users
  • Extract metadata from a metadata.psd1 -- Sadly, we can't use the module .psd1 because we can't add metadata to it, and we need:
    • License
    • Categorization
    • Optional Enhancements (modules which your module can use if they are available, but which aren't required)
    • plus all the stuff that is already in psd1 (RequiredModules, for instance)
• Downloads
  • I think we would simply provide direct access to the uploaded archive. CPAN allows you to download individual .pm files, but because of the role of .psd1 and .ps1xml files, and because they have to be unpacked to a folder by name anyway, it doesn't seem to be worth implementing in the general case.
  • The cmdlets should include the ability to retrieve all the dependencies in a single command
  • We'll wrap Import-Module to allow automatically pre-importing dependencies if they're available, and to support unpacking module zips