Chocolatey - Windows Package Manager | Hacker News Reader

Chocolatey - Windows Package Manager

chocolatey.org

86 pointsKenan52 comments

    DownloadString("http://bit.ly/psChocInstall"))

I don't think that is the best idea ever had...

Why not? There's plenty of things that are installable that way. For example:

RVM:

    bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

Homebrew:

    /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

Because you are installing programs on your computer from a "shortened URL", which could point anywhere. Your examples use a URL that is the final destination so you can make an informed decision whether you are willing to trust that URL.

If you use the "append a +" bit.ly feature, you can check where it ends up, but not everybody knows to do that. https://bitly.com/psChocInstall+

A non-shortened URL can point anywhere as well. The only way to "make an informed decision" is to put the URL in your browser—that goes for shortened and non-shortened URLs.

If I were to attack someone with such a scheme, I would take care of serving clean files to a web browser (say, with the user-agent string) and the infected files to command-line invocations. :)

Yes, that's quite a security risk, but it also affects shortened and non-shortened URLs equally.

With a non-shortened URL you have one attack vector, hack the website. With a shortened URL you have two attack vectors, hack the website or hijack the shortened URL to point to your own server.

Would providing the full link be a better idea? For the installer experience, people wanted short and memorable.

1) Those links from github are served over https, lets ignore the fact that curl might ignore it though.

2) .com isn't as potentially susceptible as a Libyan tld.

3) They are relying on bit.ly to serve the correct file.

Perhaps the full url to the github file would reduce the cryptic url?

IIRC, a few months ago there was quite a large discussion here on HNs about the reason you shouldn't do either of those.

Can't find the discussion, but there is certainly a fairly large body of people who oppose those examples as well.

I understand your specific security concerns, but the whole line is offensive. Certainly not the fault of the Chocolatey authors, but this is what I'd call a massively over-engineered shell:

  iex ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

Good thing we have bash: a paragon of both simplicity and readability!

Not sure if sarcasm or zealotry.

Except for the "iex" this isn't really Powershell specific - it's just instantiating a .NET framework object and calling a method on it. It might as well be C#.

No it might as well not be. One of the big complaints about powershell is how unclear the command line syntax for tools tends to be. A big part of developing a good C# API (or any for that matter) is clarity, readability and understanding. One of the reason fluent APIs are popular. Bad is bad, don't blame .NET or C# for that.

And yeah I realize you can come up with an ugly command line example in just about anything. But powershell tends to be one of the uglier ones out there.

We started with a much more involved set of steps to install and people kept wanting a one liner for the install. It's a tradeoff

Huh? It's calling DownloadString on a System.Net.WebClient. That IS a C# API. I'm not sure what you're talking about.

That being different from using wget or curl in bash or easy_install how again?

  wget http://bit.ly/psChocInstall

  ((new-object net.webclient).DownloadString("http://bit.ly/psChocInstall"))

If you happen to have wget, sure. Windows doesn't, by default. It is far more likely that the machine will have powershell, and if it does, it has the .net frameworks.

But, with wget, the line is

  iex (wget -qO- http://bit.ly/psChocInstall)

which isn't too bad.

That is just a way to install chocolatey. After you install, running installs is 'cinst somepackagename'

This looks like a close competitor to CoApp (http://coapp.org/) - both are FOSS package managers for Windows, although it appears Chocolatey places less emphasis on libraries and other developer-focused packages. That is, CoApp is emphasizing shipping both source and binary packages, and provides more help to package maintainers still trying to make their programs build on Windows.

Chocolatey will probably get more users early on though, because of its association with the ever-popular NuGet (watch for the Scott Hanselman blog post...).

CoApp is also backed by Microsoft, IIRC.

That and creating packages with chocolatey is stupid simple compared to what I've seen with CoApp. But CoApp also has source and WinSxS.

You can see how easy it is to create a package here: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

Would recommend changing the "cinst" command to something more memorable like "choc".

And the uninstall command? :D

What benefits (other than what looks like a scripting language) does PowerShell give over regular command prompt?

It has ls. Does anything else matter?

From what I remember it has an object oriented style, i.e. you don't have to parse text for a specific column you want (you call the appropriate method).

And you also get easy integration with the .NET libraries.

There are also lots of libraries for powershell that make it very easy to do things. For example MS provides a great way to manage Exchange via powershell. You can even go so far as getting a GUI in powershell.

As a sysadmin I use powershell for quite a few automation and management tasks on Windows servers. It is nice to have a interface to the server that I know will always be on the server and will update by itself. There is no need to install a third party scripting language just to script simple things that are difficult to do in the standard windows command line.

Here's an example, find all files recursively that are over 100k

    ls -r | ?{$_.Length > 100*1024}

Doing this in Bash or CMD would be annoying (certainly doable though!), especially the recursive part.

  find . -size +100k

I stand corrected :) I certainly don't want to start a "which is better" argument, just trying to give an example of something interesting in PSh

'ls' has -R too, if you really want to do it like that.

Of course, that form in Unix would not be suggested, because there are other far better (readable/concise) ways of doing that. (like the 'find' one someone else just gave you).

Differences between PowerShell and other *nix shell variants are that PShell allows you to pipe full COM or .NET objects between processes or commends, rather than just piping the text files between different commands.

PowerShell vs cmd.exe PowerShell is actually a complete shell scripting language, that gives you full access to all of the .NET libraries and methods. It also has a rather nice IDE that ships with Windows as is. Also, you can use PShell of Exchange and other server automation, you can do remote scripting, and it has some pretty decent security controls baked into the system.

Complete yes, but slow to start up (takes hundredths of ms, even if hot-loaded), and not very syntax friendly.

Hundredths of ms sounds pretty fast

Yes, it's okay if it's started once, but if you have to run it over and over then it's not. For example run it 10000 times, and if time it takes 300ms - you are looking at an hour of execution. Some apps (even if they are big) are just naturally cached by the OS in the file system buffers, but others are doing quite of other things before running.

If this is going to be a "shell" replacement it needs to start very fast at least in hot mode (cached).

> PShell allows you to pipe full COM or .NET objects between processes or commends, rather than just piping the text files between different commands.

Which is IMHO the best part about unix shell and the worst about PowerShell: being pure text, unix shell allows for very loose definition of the interface between the program and outside, allowing to connect stuff in creative ways with minimal plumbing; whereas PowerShell makes this interface definition quite stringent by comparison, hence needing theoretically less plumbing (at least for simple tasks) but requiring far more design in the interface, restricting connectivity which in turns generates more mediation and plumbing to connect foreign elements.

In short unix shell may seem archaic but its loose binding makes it very powerful and quick to solve problems, while PowerShell is, well, a chore.

I haven't used PowerShell (since I don't use Windows), but when using the Unix shell interactively every so often I find myself in a situation where the data is too complex for a shell command to be able to process it, or else running into some corner case of missing functionality. Usually I end up piping into python -c, but that ends up pretty gross... if PowerShell isn't the answer, what is?

I wonder how far you could get by sort of plopping PowerShell onto the Unix shell and supporting both structured and text data.

(Incidentally, one such corner case is summing a list of numbers - this sounds like it should be a short command, but actually requires a complicated command line using awk.)

I would recommend mentioning that one needs to run 'set-executionpolicy unrestricted' in the code box.

Thank you.

I had high hopes when I saw the title. I was expecting something for getting MinGW precompiled libraries like openssl, curl or boost; which I find needing more than often.

Cygwin has its own built-in package manager

Yes, but Cygwin makes your software GPL, and that's not something I can do.

If you need a sane MinGW environment, the MSys Git dev environment is by-far the easiest way to do so, it will download and set it up all in one shot.

It could be a chocolatey package. ;)

I am using the vanillia one and it is very good. The only problem I have with it is that I have to compile everything for it. Sometimes doing so is not so straight-forward and can take a lot of time, boost being one example.

cinst curl - it's there. For the others, just because they are not there yet, doesn't mean they won't be. Creating packages is pretty simple. This is the main part of the curl package: https://github.com/ferventcoder/nugetpackages/blob/master/cu...

Yes, that's true. But I need a sane build environment with development packages. I would like to be able to compile against libcurl and openssl as easy as it is on Ubuntu or Fedora. Something like Cygwin but without the GPL requirement on final builds.

I think CoApp is going to be the answer for what you are trying to do. Chocolatey starts after compilation. If someone is already providing libcurl and openssl, these are easily offered as choco packages. Once CoApp comes out, it's highly likely that there may be some integration with it.

Reply on news.ycombinator.com