Description
I'd like to suggest offering support for git/http based repositores.
PowerShellGet 2 supports only NuGet or SMB repositories. NuGet repositories like powershellgallery.com (PSG) is great as a platforum to centrally distribute (especially binary) modules.
Disadvantages of NuGet and SMB repositories
It's an entry barrier because after you commited the code to your git repository, you need additional steps to publish the module to PSG, starting by registering a PSG account and retrieving an API key. Then you must maintain the code repository as well as the PSG repository.
For company-use this is even more of a burden. Modules may be company-internal, meaning that they cannot be published at PSG. In addition to the above, you require a NuGet repository, which requires a server, a repository service and specific knowldge, which in turn requires more staff, more budget and more time. Alternatively you can rely on SMB repositories, which require nothing more than a file server. However, there may be limitations due to security concerns or file share permission management.
Advantages of git/http repositories
With git/http support, you would be able to install a module from any git server, regardless of the transport protocol. Publishing modules would be integrated into the development flow. Modules can be locally developed and pushed into any git repository, be it local or on an SMB share, on GitHub, GitLab or BitBucket. From there PowerShellGet 3 should be able to download them via SMB or http GET.
This would enable beginners or maintainers of smaller modules to keep all of their workflow on the same platform.
This would also enable companies to develop internal-use modules and distribute them using already available tools.
How it could work
Take a look at the built-in Go package management. Modules can be directly published to github (instead of something like npm or pypi) and can be retrieved and with e.g. go get github.com/google/codesearch/index.
Without knowing how Golang solved this, one example would be like this: Let's say we want to publish a module named CompanyADUserTools.
- The master branch would be the current stable version of the module. Tags are used for versioning and they must be equal to the version string in the module metadata (psd1).
- To install the module, you could do
Install-Module https://gitlab.intranet.company.com/it/CompanyADUserTools. - This would get the module from the master branch.
- To publish a new version, merge the changes into master and tag it as a new version.
- To update the module you would then run
Install-Module https://gitlab.intranet.company.com/it/CompanyADUserTools. PowerShellGet would then compare the installed version with the master branch versions, or simply just get the current master branch. - Using tags you can install older versions of the module.