New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish the module to the PowerShell Gallery #320

Closed
KirkMunro opened this Issue Sep 16, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@KirkMunro

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.

@ILMTitan

This comment has been minimized.

Show comment
Hide comment
@ILMTitan

ILMTitan Sep 16, 2016

Contributor

The problem with this that is the cmdlets do not fully stand alone. They get default values from the Cloud SDK default values, and authentication requires the Cloud SDK "gcloud auth" command. This is why they are packaged as part of the Cloud SDK installer.

Contributor

ILMTitan commented Sep 16, 2016

The problem with this that is the cmdlets do not fully stand alone. They get default values from the Cloud SDK default values, and authentication requires the Cloud SDK "gcloud auth" command. This is why they are packaged as part of the Cloud SDK installer.

@chrsmith

This comment has been minimized.

Show comment
Hide comment
@chrsmith

chrsmith Sep 22, 2016

Contributor

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 gcloud tool.

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.

Contributor

chrsmith commented Sep 22, 2016

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 gcloud tool.

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 chrsmith closed this Sep 22, 2016

@KirkMunro

This comment has been minimized.

Show comment
Hide comment
@KirkMunro

KirkMunro Sep 23, 2016

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.

KirkMunro commented Sep 23, 2016

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.

@chrsmith

This comment has been minimized.

Show comment
Hide comment
@chrsmith

chrsmith Sep 23, 2016

Contributor

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 gcloud for some cmdlets. (We don't know, but probably will for the deployment ones later.) Then some of the mechanics would be more difficult. We'd need to download a ~40MiB Python runtime, and the related source files from the Cloud SDK to run them. And since those source files are updated every week, our clone would quickly become out of date. So if we and up with the shell out to gcloud that would greatly complicate the PowerShell Gallery story.

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.

Contributor

chrsmith commented Sep 23, 2016

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 gcloud for some cmdlets. (We don't know, but probably will for the deployment ones later.) Then some of the mechanics would be more difficult. We'd need to download a ~40MiB Python runtime, and the related source files from the Cloud SDK to run them. And since those source files are updated every week, our clone would quickly become out of date. So if we and up with the shell out to gcloud that would greatly complicate the PowerShell Gallery story.

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.

@chrsmith chrsmith reopened this Sep 23, 2016

@quoctruong

This comment has been minimized.

Show comment
Hide comment
@quoctruong

quoctruong Mar 20, 2017

Member

@KirkMunro we just published the module to the gallery! Please give it a try.

Member

quoctruong commented Mar 20, 2017

@KirkMunro we just published the module to the gallery! Please give it a try.

@ILMTitan ILMTitan closed this Oct 27, 2017

@KirkMunro

This comment has been minimized.

Show comment
Hide comment
@KirkMunro

KirkMunro Oct 27, 2017

I meant to come back here and thank you guys for this, but life is ever distracting.

Anyhow, thank you @quoctruong, @chrsmith, and the rest of your team for following through with this. It is greatly appreciated. :)

I meant to come back here and thank you guys for this, but life is ever distracting.

Anyhow, thank you @quoctruong, @chrsmith, and the rest of your team for following through with this. It is greatly appreciated. :)

@quoctruong

This comment has been minimized.

Show comment
Hide comment
@quoctruong

quoctruong Oct 27, 2017

Member

@KirkMunro You're welcome and thank you for all the great feedback about the module!

Member

quoctruong commented Oct 27, 2017

@KirkMunro You're welcome and thank you for all the great feedback about the module!

@quoctruong

This comment has been minimized.

Show comment
Hide comment
@quoctruong

quoctruong Nov 27, 2017

Member

@KirkMunro Hi Kirk, just want to let you know that the newest version of the module on the gallery now also works on .NET Core! Feel free to give it a try.

Member

quoctruong commented Nov 27, 2017

@KirkMunro Hi Kirk, just want to let you know that the newest version of the module on the gallery now also works on .NET Core! Feel free to give it a try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment