CPAN and PoshCode vNext

I want a Comprehensive collection of PowerShell Code

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 information about commercial modules, so they're searchable
• Support ownership of modules. Meaning once you claim a module name, nobody else can use it. 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
• 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).
• Provide a new PoshCode Module using the API
  • Search modules, and search for commands
  • Be able to "upgrade" all your modules to the latest versions
  • Be able to download modules by name, including their dependencies (recursively)
• Documentation (look at CPAN). We need to allow basic (searchable) module documentation, plus documentation per cmdlet/function, plus examples.  Really, this should probably be wiki pages.
• Simple script sharing. 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!
  • Perhaps we should take a cue from MSDN Code gallery: documentation wiki, issues, and comment forum?
• 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