Kinda like apt-get, but for Windows
chocolatey.org
chocolatey.org
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.
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.
So, that's just one file?
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.
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.
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.
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.
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.
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.
Well, Him and the designers of the operating system.
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.
All explained here:
http://superuser.com/questions/384107/why-cant-i-edit-a-prog...
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.
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.
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...
There should be. Choclatey "uses the NuGet packaging infrastructure" and NuGet has that.
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
Class Test Public Shared Sub Main() Console.WriteLine("GetCommandLineArgs: {0}", String.Join(", ", Environment.GetCommandLineArgs())) End Sub End Class
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.
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.
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 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.
The default is in c:/chocolatey/. Oddly, chocolatey agrees with me. You are welcome to change that in your configuration, however.
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
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)
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.
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.
"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.
Which brings me to question why this is news, as the homepage (and the analogy) has been there for quite some while.
https://groups.google.com/forum/#!msg/chocolatey/odIIsCLfww8...
Gary
This is one of the reasons that Windows boot takes forever.
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.
[1] https://github.com/chocolatey/chocolatey/wiki/ChocolateyVsNi...
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.
Edit: It doesn't track dependencies, though, which probably makes it less useful for that purpose.