Comment by sjellis | Hacker News Reader

Comment by sjellis | Hacker News Reader

Parent Full thread

The ecosystem creates problems that don't exist with PowerShell, which is more like a cross-platform programming language that sits above the OS than the traditional *NIX arrangement of an OS-specific collection of a shell (with some built-ins) plus a grab-bag of third-party tools.

Like Python, Node.js etc., PowerShell has one development team that will now be delivering one implementation across all of the operating systems. There's a packaging system included, so that third-party modules can also be uniformly deployed. The first-party and third-party stuff all has to follow the same rules and end up as modules in the same PowerShell installations, which avoids the long-running inconsistencies between tools, like man vs. info and different styles of option parsing.

At the moment, different versions of Windows do ship with different versions of PowerShell, which is annoying, but it's the same product and you can install new PowerShell versions on older systems to get a consistent environment across your machines.

The UNIX philosophy of "do one thing, well" and "write many programs that work together" is contrary to powershell's idea of having all the tools you need as built-ins to your shell. The minute you need something that the "one development team" hadn't thought of, or decided wasn't important enough to ship, you have to either port it to powershell as a plugin or write something more complex to handle your workflow. For all it's cruft and baggage, the fact that there's not "one way to do things" and is continually expandable is part of what endears UNIX to it's users.

The fact that PowerShell needs modules to fully work with something is definitely an issue - we'll have to see whether people start writing the modules to make PowerShell fully functional on *NIX. You can call existing command-line tools, or methods from the underlying .NET Core installation, but those are really just work-arounds.

To be fair, every programming or automation platform has that issue: Python and Ansible succeeded because people did like the basic systems enough to write code to extend their usefulness.

Thanks, I didn't know about the packaging system. So the idea is that the ecosystem is made of PowerShell (i.e. the shell itself and PowerShell scripting language) + .NET + 3rd party packages, am I right?

Oh I actually did know about the package manager, but I didn't know that that's coming to *NIX through PowerShell. For reference: https://blogs.technet.microsoft.com/packagemanagement/2015/0...

If I remember well, some time ago MS announced that on Windows you would be able to use Chocolatey as an additional source, which I thought was interesting.

PowerShell itself now has a packaging system and public repository for modules: http://www.powershellgallery.com/

PowerShell for Windows got this earlier in the year, and it's part of PowerShell Core. So with PS Core, you should be able to start a freshly installed copy of PS on whatever OS you are using, and add the AWS modules with this command:

Install-Module AWSPowerShell.NetCore

(Warning: this command does not work on the alpha release due to a bug - you need a workaround as described on the AWS blog: https://blogs.aws.amazon.com/net/post/TxTUNCCDVSG05F/Introdu...)

Nothing very impressive to anybody that has used any modern programming language, but now your shell has this too (if you use PS).

Thanks, I had a look and it's interesting, do you know if the Power Shell Library is just a distribution channel based on the Win 10 package management system that I linked in my previous comment, or is it a completely separate product?

AIUI, PackageManagement really is literally just a convenience API for providing a consistent set of calls for driving arbitrary package management systems, and has no package management capabilities at all itself. It's actually not Windows-specific.

The actual package management system for PowerShell modules is PowerShellGet.

On Mac, PowerShell Core includes PackageManagement, and two "providers" - an adapter for PowerShellGet and one for NuGet, so you seem to be able to do either:

Find-Module AWSPowerShell.NetCore

(to use PowerShellGet directly)

Or:

Find-Package AWSPowerShell.NetCore

(to go through PackageManagement)

Urgh, double-post and no edit or delete options - thanks, HN.

Thanks for the (double :-) ) explanation! This kind of capability in PowerShell is definitely interesting.

The actual package management system for PowerShell modules is PowerShellGet. AIUI, PackageManagement really is just a convenience for providing a consistent set of PowerShell commands for driving arbitrary package management systems, and has no package management capabilities at all itself. It's not Windows-specific, and seems to have been made cross-platform with PowerShell itself.

On Mac, PowerShell Core includes PackageManagement, and two "providers" - an adapter for PowerShellGet and one for NuGet, so you appear to be able to do either:

Find-Module AWSPowerShell.NetCore

(to use PowerShellGet directly)

Or:

Find-Package AWSPowerShell.NetCore

(to go through PackageManagement)

I didn't know most of this until I started poking around, so thanks for asking!

Reply on news.ycombinator.com