Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Publish the module to the PowerShell Gallery #320
Related to #314, you can completely avoid that problem by packaging up your module and distributing it via the PowerShell Gallery. The PowerShell Gallery is absolutely the preferred way to distribute PowerShell modules, and it makes it much easier for anyone taking a dependency on your module. If you do decide to go this route, please don't publish the module to the Gallery until after you address name issues that are discussed in #315.
If you would like more details on why you should distribute via the Gallery instead of via a downloadable installer (or in addition to, I suppose, but really I don't see the value of a downloadable installer for a PowerShell module at this point), let me know and I can talk about it.
Yes. We want to think of the PowerShell cmdlets as dependent upon the Cloud SDK, since otherwise you would have to potentially manage your credentials in two different ways. Also, it allows us to potentially cheat in the future and write cmdlets that are built on top of the
Publishing to the PowerShell Gallery is a good thing to keep in mind however. As there might be a subset of our cmdlets that work without cloud credentials, and could be distributed outside of the Cloud SDK installer.
chrsmith: Just because the module requires functionality that is available in your Cloud SDK doesn't mean that the entire Cloud SDK has to be shipped with the module. Why don't you just package up the DLLs and/or other components from your SDK that are required by the module in the module itself as part of a build step, and then publish the module to the Gallery with everything it needs? Azure PowerShell modules require SDK components in order for them to work correctly, and those modules ship with what is required from the Gallery. Amazon AWS has a PowerShell module that is available via the Gallery, and it includes what is required to get the job done. This is just a packaging issue. I doubt you need your entire SDK in order for the PowerShell module to work. You more likely simply need some binary files that provide the functionality that is needed.
You should look at this the same way that you would look at someone building a product on top of your SDK (in this case the product is the PowerShell module you are providing). Do people building products on your SDK need to ship the SDK (which would be ridiculous)? Or do they ship binary components or some redistributable package that provides the required functionality that they built against using that SDK?
I strongly encourage you to reopen and reconsider this issue. I feel you really aren't seeing the big picture why this is really the only way that modules should be delivered. There may be some architectural challenges with how you currently have the cmdlets implemented, but getting the module into the Gallery in such a way that it can be installed and be fully functional (including cloud credentials) using PowerShellGet should be a goal on your radar.
Thanks @KirkMunro , I appreciate the feedback and additional insight. I agree that this is just a matter of packaging. The nuance is that the Cloud SDK unfortunately isn't just a set of tools or assemblies we can copy to the machine. Instead it is a pretty complicated Python application, which also has a undocumented subsystem for managing local credentials. i.e. it isn't that the PowerShell cmdlets are built on top of the Cloud SDK. Instead, we are relying on implementation details of the SDK.
We could probably codify the credential and configuration handling parts, so that PowerShell could read/write the files in a compatible way even if the SDK isn't on the machine. That's definitely a very attractive feature that we should investigate.
However, if we do end up selling out to
Anyways, we'll reopen this issue and look into how we could make this happen. Being able to use PowerShell and the Cloud SDK independently would be a better end result, and if we can get to that point then there would be no reason not to publish our modules to the Gallery.
We definitely won't be able to get to this in Q4, but we'll keep this issue around. Thanks for pushing back. We definitely appreciate the expert feedback, as many of us at Google are relatively new to PowerShell and the greater community, best practices, etc.