Hacker News new | past | comments | ask | show | jobs | submit login
Kinda like apt-get, but for Windows (chocolatey.org)
140 points by franze on Feb 6, 2013 | hide | past | favorite | 101 comments



The problem that I have with chocolatey is: It's all about the installs. You'd hope that the people doing it would know how installs work.

But the default place where chocolatey installs is "C:\chocolatey", and "C:\" is where people who don't understand windows file system layout put things.

The docs ( https://github.com/chocolatey/chocolatey/wiki/DefaultChocola... ) make a plausible case that this option might be justified sometimes. Saying "we'll always put it somewhere nonstandard because some people might sometimes want to install it when they don't have permissions to put programs where they belong" is unconvincing.

The other argument put forward "It's not installed through the registry" (so?) and "it's a Special core component tool" (it's not special to anyone who hasn't installed it yet) are equally weak.

This choice of install folder should arguably be allowed. But it's a rubbish default, a poor first impression and undermines confidence that they know what they're doing. It is inexcusable that "C:\Chocolatey" is default and "C:\Program Files\Chocolatey" is a set-up that one does manually.


I have tested Chocolatey, it's definitely not perfect but does its job.

Anyway, I can recommend it to anyone with a Linux background who plans unattended/automated installations on Windows Machines in small scale. It's easy to script and if you want to add registry entries yourself in a post-install script, it's dead easy.

In this context I absolutely agree to the argument "nonstandard because some people..." A common use case for Chocolatey is probably the installation on computers of users who cannot manage the systems for themselves. I think it fills the gap for small scale (semi-)automated installations. I bet for large scales Microsoft has some kind of solution.


Yes, the large scale solution from Microsoft is System Center Configuration Manager, which I use extensively at work. SCCM has a lot of strengths, but it's not really suited to small operations: it has a lot of complexity that smaller orgs simply wouldn't use. Doing something simple like pushing out the latest version of Firefox without customizations, aside from the time it takes to find and download the file, still takes a good number of steps afterwards. It's a sledgehammer when some people just need a mallet, and it also costs a good amount of money!

Active Directory users can utilize Group Policy for software deployment, but that has its own share of caveats (I haven't used it in a while, but last I checked deployed apps have to be an MSI).

The thing that appeals to me about Chocolately is that it does the work of going out and getting the package for you. If you're in an environment where you don't need to do any customization of packages, this seems like a way to save time and energy over using Group Policy. However, there doesn't seem to be any reporting capability nor is there a way to initiate deployments from a central server (I guess the idea is to designate a startup script in Group Policy or just have users type commands themselves). Even in a small environment, those two features really help with management.

It'd be nice if there was a way to create a local distribution point in order to minimize bandwidth usage. But that would be a big project in itself...


> It'd be nice if there was a way to create a local distribution point

There should be. Choclatey "uses the NuGet packaging infrastructure" and NuGet has that.


IME "root of C: drive" default install location is often a sign that software has bugs when run from paths containing space characters.


If the app writes files into the installation, then you can't install in "Program Files", because Windows will capture and redirect those writes.

Cygwin goes to c:\cygwin because it's normal for all sorts of files in that directory to be written/changed. If it were in "Program Files", it wouldn't work at all.

To call this a bug is just absurd. It's Microsoft that changed the notion of what was valid and forced everyone else to conform. Some software isn't able to conform.


Well written software follows guidelines from the NT age (%APPDATA%, %PROGRAMFILES%, etc). I have no idea why people still think its the dos age of just making arbitrary folders on the root. Heck, this is currently a huge problem in android. The root of my /sdcard is a mess. Are we forced to relive every mistake with every new platform?

I have no idea what capturing and redirecting writes mean. If you want to write, write somewhere you have permission to write to. I deploy software and sometimes need to changeup permissions for badly written software that likes to write to its install folder. I don't know why people excuse developer laziness like this. Imagine if your linux configs were written to /bin/ instead of /etc/ or stuff that should be in your profile is written to /sbin/ or if your logs were put in /etc/. Thats the linux equivalant of what lazy developers do to Windows.


I have no idea what capturing and redirecting writes mean.

All explained here:

http://superuser.com/questions/384107/why-cant-i-edit-a-prog...


Yeah that's still a permissions issue. The user/account did not have write permissions so instead of just erroring out its trying to preserve legacy software by taking the change and ignoring it silently. Who knows why MS chose this path but the fault is still on the installer.

The fix is either use the proper locations for app data OR change permissions on that folder. its not some insurmountable hurdle that forces you to use weird locations. If permissions were correct then it would be fine. Heck, install Apache on windows. Everything just works in the proper locations because they didn't half ass everything.

Its also worth mentioning that this change came along when Vista was released; prior to that this didn't happen, yet crappy installers pulled the same shit: install to c:\, attempt to write to c:\windows\temp, etc and other DOS/Win95 legacy habits.

Ironically, Vista helped fix all this. Now I see installers for open source or community projects uses proper locations much more often than not. I guess people got sick of the UAC prompts and corporate admins were complaining about how all these arbitrary writes weren't compatible with their limited users.


Apps should write data files to %APPDATA%, not Program Files where the executables shall reside. The only excuse for installing to c:\chocolatey is lazyness


In this case, Chocolatey's data files are actually program files for the rest of the system.

It's just a simple consequence to the fact that Chocolatey is not 'a program' with clearly defined 'data files', but a general purpose software manager (and one that should really be a part of Windows).

The Von Neumann architecture won over the Harvard architecture for a reason. You should learn about it.


> The Von Neumann architecture won over the Harvard architecture for a reason

And then we placed restrictions on it for another reason: security.

See Data Execution Prevention http://en.wikipedia.org/wiki/Data_Execution_Prevention Which, like these file system permissions, attempts to divide storage into things that you can write and things that you can execute, and the two only meeting in special cases.

You're saying that Chocolatey needs elevated privileges to do it's special thing. Sure. Then it shouldn't be designed around the needs of users who can't get those permissions.


This is just plain naive. See Shorel's comment, and to that I'll add:

That is YOUR definition of where to write data files. Not mine and certainly not everyone's idea. Saying that all apps should fit this model is just absurd.


> That is YOUR definition of where to write data files

Well, Him and the designers of the operating system.


My point is they changed the definition. It wasn't always that way.


You'd prefer that nothing changed? OSs evolve. Deal with it.


like c:\oracle?


and C:\Python27


For Python what may be happening is a good piece of software that is not native to Windows. It works well enough on Windows, but the windows installer is very low on the developers' priorities and expertise. So the windows install experience ends up an afterthought that just barely works.

It also shows how anyone claiming "my tool is special, unlike others it's better to install this under C:\" is not showing good neighbourliness. It just encourages others to make the same mistake.

For Oracle, that probably also holds ... except maybe for the "good software" part.


Yep. That's old-school though, you don't see much of it these days.


I never understood what is so hard in treating the space as just another character.


Because space is not just another character. Space separates args.


But an installer talking to the operating system shouldn't need to separate arguments anywhere.


Which is why escape characters and quotations were invented


It is an abject failing of software that perfectly reasonable characters are barred from filenames.


which is why most arguments tend to have a way to be recognized like -, -- or /


Those are how one differentiates flags from arguments, which is a separate problem.


Kind of.

If your flag is for a path, you can assume everything up to the next flag is a path name.

myprog -filename here is my path with spaces -another_flag

Of course this depends on how the shell gives the arguments to the program.

On the other hand, there is no excuse why some GUI programs cannot handle spaces.


cp path1 path2

So, that's just one file?


Treating the space as just another character in a path means that sometimes paths have to be placed inside quotes so the space isn't taken for the end of a commandline arg. Some old software didn't do that.


Chocolatey is not old software


No, it does not have that excuse.


But the packages it installs may.


The tilde file names in windows harken back to ye olde days of MSDOS, where file names were only allowed to be 8 characters long, and the extension was only allowed to be a dot followed by three characters (aka: the "eight-dot-three" file naming convention).

Like, if someone generated several thousand files, all named: "New Text Document.txt"

In the background, some versions of Windows will also record an alternate file name for ye olde backwards compatibility, such as:

NEWTEX~1.TXT

NEWTE~10.TXT

NEWT~100.TXT

NEW~1000.TXT

NE~10000.TXT

N~100000.TXT

It's not really about the space characters, so much as it is about length constraints from back when 640KB should've been more memory than anyone will ever need.


Couldn't you do PROGRA~1 for "Program Files" or PROGRA~2 for "Program Files (x86)"?


If there were another directory like "Program Aardvarks", then the DOS names wouldn't necessarily be PROGRA~1 and PROGRA~2


From their FAQ, it says that chocolatey is "CLI focused". So, "C:\chocolatey" makes sense. Paths with space are definitely less CLI-friendly than those without.


Does install location matter to the CLI? The install location will be on path, so it will be usable from anywhere.


Well rather, if you want to muck about in the installation folder, typing "C:\choc<TAB>" is easier than "C:\Progr<TAB>\choc<TAB>"


Show me a CLI that doesn't auto-complete paths with spaces. I don't remember when I last had to type “Program Files (x86)” out in full.


When you write CLI apps in .NET, for example, handling paths with spaces is a mess (argv splits on " ", even if you wrap arguments in quotes, so "C:\Program Files (x86)" is seen as 3 tokens.


Really?

    C:\Users\andrewj\Desktop>type test.cs
    public static class Test {
            public static void Main(string[] args) {
                    foreach (string arg in args) {
                            System.Console.WriteLine(arg);
                    }
            }
    }
    C:\Users\andrewj\Desktop>csc test.cs
    C:\Users\andrewj\Desktop>test.exe a b "C:\Program Files (x86)" d e
    a
    b
    C:\Program Files (x86)
    d
    e
Do you mean "language x" on .NET?


VB.NET shows the behavior with

Class Test Public Shared Sub Main() Console.WriteLine("GetCommandLineArgs: {0}", String.Join(", ", Environment.GetCommandLineArgs())) End Sub End Class


I hate programs that always put junk in C:\Progra~1. I've put my programs in C:\ since my pre-Win95 DOS and OS/2 days. IMHO there's nothing wrong with installing in the root of the drive, especially if it's only a default that you can change if you want to.

In fact, as far as I'm concerned, InstallShield(R) Wizard -- and the idea of installers in general -- is a piece of crap. I want my installer to be an editable batch file that just copies the files to C:\ -- and does any other setup if necessary. Not that other setup is usually actually necessary, but a lot of apps feel a need to call home over the Internet, install a ton of stuff on my desktop, my Start menu, my Windows directory, all over the Registry, etc., as well as transfer the damn executable from the CD-ROM to my hard disk, which is all a well-written program should really need to do.

I want to actually see what the program's doing, so I can keep track of the pieces. I can't count the number of times I've had to delve into C:\Users\Whoever\Applic~1 or C:\Progra~1 or C:\Progra~2 (on 64-bit Windows) or C:\IDontEvenKnowWhat\Users\Whoever\Whatever\Profiles\Roaming\TheCompany\TheApp to find my saved game so I can continue my adventure on another PC. Or had to regedit.exe into HKEY_LOCAL_MACHINE\Software\TheCompany\TheApp\TheSetting and edit some hex value when a plain-text configuration file in C:\PROGRAM would have been perfectly adequate.

I've been using Linux for years now, and frankly it isn't much better -- install $PKG and you might get /usr/bin/$PKG, /usr/lib/$PKG, /usr/share/doc/$PKG, /usr/share/$PKG, /var/$PKG, /var/log/$PKG, /var/run/$PKG, /etc/$PKG, /etc/init.d/$PKG, /var/www/$PKG, /home/$USER/.$PKG -- part of the reason for having a package manager is to stay in control of this sprawl. The simple and obvious solution of putting $PKG in /$PKG or /opt/$PKG is too much to ask, of course, since it breaks compatibility with the first UNIX where /usr/bin is different from /bin because the system outgrew the specific hard drive the developers were using, so they had to split some things off into a second drive, which was mounted at /usr.


> I've put my programs in C:\ since my pre-Win95 DOS

I see your problem, you're confusing WinNt from the Vista-and-after era with MSDOS.

> IMHO there's nothing wrong with installing in the root of the drive, especially if it's only a default that you can change if you want to.

I disagree, the default is in C:\Program Files. Oddly, windows agrees with me. You are welcome to change that on your system, however.


Technically, you agree with Microsoft, not the other way around. Also, I don't see what the big problem of chocolatey installing where it does. Cygwin, MinGW, Python, Ruby and others do it, too?

The default is in c:/chocolatey/. Oddly, chocolatey agrees with me. You are welcome to change that in your configuration, however.


> Technically, you agree with Microsoft, not the other way around.

shrug that's much the same.

> Also, I don't see what the big problem of chocolatey installing where it does. Cygwin, MinGW, Python, Ruby and others do it, too?

They're wrong too, as mentioned in this thread http://news.ycombinator.com/item?id=5176323 and this one http://news.ycombinator.com/item?id=5176685


Maybe it would be better to call it, or actually make it, a portable install?

Imagine making it install to a folder in your Dropbox - then any machine you put your Dropbox on you can run those apps?

(Disclaimer, I pay for the 100GB Dropbox, so I am not concerned about space)


Over at coapp.org, we are (were) doing this the "right way", with MSIs that install into Program Files and dependency management.


To be clear, that is exactly what chocolatey does as well. The "package" is placed into the C:\Chocolatey folder, but the MSI installs to it's default location, which is typically the Program Files folder.


I don't understand. What would be the correct default install location?


c:\Program Files, like every other program since Windows 95.


And technically you should just use the 'ProgramFiles' environment variable, since the folder might be called something else if your install is in another language.

And Windows allows side-by-side installs of 64- and 32-bit versions of the same software; so installers should be aware of 'C:\Program Files (x86)' and 'C:\Program Files'; the first is for 32-bit programs on 64-bit machines.



As a followup, what is supposed to go into C:\? I've always thought it was awful that Python gets installed into that directory.


I don't think that the user or an installer should put anything directly in C:\. I agree, it is awful that python goes there.


It's the same as going "I'll just save this folder on / so I don't have to remember the path later".


It is not awful.

I've put junk in the root of my drives since before Windows 95. Installers that default to putting junk C:\Progra~1 are what's awful.


Seems to me like having the infrastructure in place is only a first step. It's only as valuable as the packages available within the infrastructure. And having a useful set of up-to-date packages is a huge amount of continuous (!) work. You need a lot of volunteers for that, or, ideally, the cooperation of the upstream developers.

It works very well for Ubuntu (and mostly, I think, plain Debian), as the Debian package archives are very good in the first place, and beyond those there is an ecosystem of volunteer or developer maintained PPAs, and beyond those there are individual .debs released by volunteers or devs that you can plug in, sidestepping the server requirement.

It's a cultural difference. It took me quite a while to adapt to it when I switched from Windows to Ubuntu; I was extremely sceptical at first, though now I love it.


Apparently they are relying on upstream binaries and installers to reduce the package maintainer workload. In my opinion that is a sub-optimal solution.


I do not think apt-get means what you think it means.

Chocolatey seems to implement a subset of the functions that apt-get is useful for.

On Windows if I want to look for system updates, I use Windows update. On Debian I use apt-get.

On Windows if I want a library to use on a project, I use NuGet. On Debian I use apt-get.

On Windows if I want to install a bunch of free applications, I probably will use ninite, but chocolaty looks like a nice replacement for this. On Debian I use apt-get.

That said chocolatey seems like a nice tool for windows.


No need to be pedantic. The OP used apt-get as a good enough analogy and got the point across quite clearly. It let's you install things quickly, just like apt-get.

"But with apt-get you can perform searches not just exact name ma-"

Nope. Don't be pedantic. You got the point, that was the intention.


Not only OP. Chocolatey.net uses that analogy themselves on the front page.

Which brings me to question why this is news, as the homepage (and the analogy) has been there for quite some while.


Your point being? The title says "Kinda", after all. It's a good analogy.


I don't think you understand what the word "like" means. It is a word used to convey similarities, and not exact sameness. The OP states that chocolatey is LIKE apt-get for Windows, he does not say that choclatey IS apt-get for Windows.


What's the difference between "git" and "git.install", or between "7zip" and "7zip.install"? It seems that there's a dependence between the bare-named package and the "install" package, but the package description doesn't explain which one I should use if I just want the familiar app.



I've had to do some Windows development recently and as someone who switched to Linux 4-5 years ago, package management is what I miss the most (although I miss a whole host of things). I can't believe how much time I lose browsing web sites, downloading packages, unzipping, and click installing them. I look forward to trying this out.


Setting up the system once is only half the problem. Most power users have a whole host of links of tools that they will usually need and install on a new machine, but things get really ugly when your stuff gets out of date and the applications don't update themselves. IMO this is the much harder problem that is solved by package-managers. The Windows Way requires each application to replicate some auto-update process which is a great recipe for disaster.


> each application to replicate some auto-update process

This is one of the reasons that Windows boot takes forever.


Why is there a git.install and a git? The descriptions don't seem different. notepadplusplus also has two flavors. That should be explained in the description.



Awesome. The closest thing before this was ninite.

Windows really needs a good, clean (and usable for the average computer user) solution similar to apt-get that isn't controlled by someone like Microsoft.


Also interesting is Ninite [1], which lets you create a lightweight installer .exe to download and install multiple applications (e.g. Skype, Chrome, iTunes). Whilst along the same lines as Chocolatey, Ninite seems to be aimed more at "apps" than "packages" and is something you could save on a USB stick or send to less tech-savy people.

[1] http://ninite.com/


Just read the Chocolatey vs Ninite comparison [1]. For me, the biggest selling point of Chocolatey is its decentralized nature, making it useful for enterprisey deployment.

[1] https://github.com/chocolatey/chocolatey/wiki/ChocolateyVsNi...


Too bad windows cmd is so fantastically horrible. This looks like a good project though.


PowerShell's a massive improvement, but the terminal itself hasn't changed in ages (barely any change since NT4/W95 if I had to guess). There's replacements, but you can't count on arbitrary servers having them installed.


Use Powershell and ConEmu


Perhaps you will find this useful: https://code.google.com/p/clink/


Great! Now I am using cmd + clink + console2. Very natural solution... I have found powershell to be slower/less responsive for some reason


Any advice on how to make these 3 tools work together? I scanned the web and experimented today for approx 1 hour but didn't succeed. My general efforts were: (i) injecting clink into the Console2 process (ii) hosting the injected cmd process in Console2.


I actually did nothing special, I just installed clink as executable. Tested it in cmd.exe (you will get the message about running clink). Afterwards added a tab for cmd.exe in console2 and it worked. Whas seems to be a problem for you?


Hi, thanks for the info. The initial difference is that I cannot use the installer due to Windows group policies associated with my account (the PC is not mine to administer). So I've downloaded and extracted the v0.3 zip archive.

I manually start clink by running "install_dir\clink inject" in a cmd session and this procedure works correctly. Problems arise when running the same command in a cmd session in Console2. The Console2 process disappears (crashes?) after approx 1 sec, then 10s later the clink executable disappears. Strange behaviour and I may simply drop this and perhaps try again in future once the tool(s) have matured.

I hadn't used either Console2 or clink before now; I can get by without them as I'm not a rabid user of the Windows command line. I'll likely casually experiment with them separately.


Try out ConEmu instead of Console2. It also has clink integration from the box.


Glad you like it! (My brother is the author. :])


I use pycmd -> http://sourceforge.net/projects/pycmd/ Also tried console2, and zsh win32 variants i found.


It's better but not really great. I just don't understand why it has to run within the cmd environment, which is horrible. I use Git++'s shell as my go-to cmd in windows but that's about the same. Why can't it be a complete application that would emulate the "cdm" under the hood? So I can get the feel of a real (as in anything you install on linux) terminal application.


Console2 + msys bash is bearable.


Try clink (search on google code), it brings bash to cmd.


I think it's problematic that the package list on the chocolatey website doesn't show the version numbers of the apps. If I install that Python package, would it be 2.7.3, 3.2, or another one? Ninite does this well on their website.


The version number is clearly visible on the website: http://chocolatey.org/packages/python


What if the user installs VLC (which is horribly outdated there) and then, installed VLC, using internal update mechanisms, gets updated? How will that "system" behave then?


As far as Chocolatey is concerned, you still have the originally installed version.


The "easy install" is barely tweet-able its so long. Man I'm thankful for curl x | sh. Nice work on this but it has a major flaw. Windows.


2013 -- the year Windows gets a "package manager".


This was released at least 2 years back (http://nuget.org/packages/chocolatey)


Windows Installer is a package manager, in a way (it keeps track and manages installed packages – it doesn't help you find them, though).

Edit: It doesn't track dependencies, though, which probably makes it less useful for that purpose.


You mean the Windows 8 Store?


I like the project - I used it together with powershell to do frontend development with yeoman on a friends machine. w


The important question... Can I bundle an Ask toolbar with my package?


Unfortunately yes. I used chocolaty to install speccy and got Google Chrome and Google Toolbar installed -- silently.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: