Windows can't install into anything other than C:\opscode

[juliandunn]

If you try to install ChefDK into anything other than C:\opscode, the install completes, but none of the commands will run:

C:/Program Files (x86)/ChefDK/chefdk/bin/chef:44:in load': cannot load such file -- c:/opscode/chefdk/embedded/apps/chef-dk/bin/chef (LoadError)
from C:/Program Files (x86)/ChefDK/chefdk/bin/chef:44:in <main>'

Examining all the .bat files, they have c:\opscode hardcoded into them.

[danielsdeleo]

FWIW, installing to program files is pretty much never going to work or be supported. The ruby installer FAQ used to give you a real explanation but now it's just a smartass answer (https://github.com/oneclick/rubyinstaller/wiki/faq#no_pgmfiles). But anyway, it's a fact of life that we can't fix every ruby gem or C library a gem might use to support paths with spaces in its build process or other code.

[sersut]

@danielsdeleo agreed. But from @juliandunn's description sounds like we can't install to c:\my_org\chefdirectory as well due to hardcoded strings in bat files. Does appbundler need a change?

[danielsdeleo]

@sersut probably. That said, what's the benefit of relocating the install if you can't install it into Program Files ? Can the installer prevent you from doing that? If we let you specify the install location, without a good way to prevent you from installing to a path with spaces, a lot of people are gonna run into this issue over and over.

[sersut]

Having multiple chef installations might be a corner case scenario. E.g. for teams that are building CI infrastructures that builds chef-client 😸

I think we can leave this issue open and see the commonality. Based on the feedback we can turn changing the install directories off.

[danielsdeleo]

I'd rather close it wont fix and let people add to the discussion if they have a compelling use case.

[sethvargo]

👍 ^

[juliandunn]

A compelling use case to specify the directory location is that many people who work in Windows have a very small C: drive, or the corporate convention is to install to D: (or some other drive letter). So you need some way of letting people do that.

Not letting people install in C:\Program Files is definitely not delightful, but if you say it simply doesn't work and the DevKit people can't or won't fix it, then that's not an argument I'm gonna win.

[danielsdeleo]

Yeah, it's not the DevKit people's fault. You can go through the bug reports for the project to see quite a few examples of this being a problem. There's a more informative explanation here (which used to be a lot easier to find) https://github.com/oneclick/rubyinstaller/wiki/Troubleshooting#for-some-strange-reason-it-fails-to-install-gems

[danielsdeleo]

See also oneclick/rubyinstaller#135 which has some info about UAC problems that occur when installing to program files and a pointer to this: https://github.com/ruby/ruby/blob/trunk/win32/README.win32#L132-135

[juliandunn]

So I read a bunch of the prior art you pointed to, and I also came across this bug, which apparently was fixed >1 year ago in Ruby 2.0.0 so now you can compile extensions in directories with spaces in them: https://bugs.ruby-lang.org/issues/7036

The lines you pointed to in README.win32 date from 2000-08-03 so I am not sure if they are trustworthy.

That said -- the UAC concern is legitimate. So maybe the right answer, as the poster pointed out in oneclick/rubyinstaller#135, is to default to something like C:\ProgramData\Chef. Surely MSFT has some standards about this...

Paging @adamedx to this thread. (We've had this conversation in the context of chef-client itself, too.)

[danielsdeleo]

Even if ruby works correctly, we can't account for all the gems that might generate a Makefile with something like -IC:\Program Files\blahblah as part of their build process. I'm of the opinion that having something seem to work at first and then hit this problem and have the solution be "reinstall everything in a different path" is a lot less delightful than disallowing installs to a path with spaces.

[btm]

I want to +1 @juliandunn on not being able to install to other drive letters will be a blocker for entire shops.

[tknerr]

Also 👍 for being able to specify an alternate install location (I need it for bill's kitchen :-)). 100% fine with no spaces in the directory. Can that be checked in the installer?

[tknerr]

Workaround: in x:/path/to/opscode/chefdk/bin/knife

replace:

$:.unshift "c:/opscode/chefdk/embedded/apps/chef/lib"
Kernel.load 'c:/opscode/chefdk/embedded/apps/chef/bin/knife'

with

$:.unshift "#{File.expand_path(File.dirname(__FILE__))}/../embedded/apps/chef/lib"
Kernel.load "#{File.expand_path(File.dirname(__FILE__))}/../embedded/apps/chef/bin/knife"

...and for the other commands as well...

[tknerr]

@juliandunn @danielsdeleo also noticed: some commands e.g. foodcritic do not force usage of the embedded ruby, e.g. in opscode/chefdk/bin/foodcritic.bat:

...
:WinNT
@"ruby.exe" "%~dpn0" %*

Should rather be:

...
:WinNT
@"%~dp0\..\embedded\bin\ruby.exe" "%~dpn0" %*

Otherwise it would use the system ruby instead. See also chef/chef#1512 (comment)

[tknerr]

Just checked, this is still present in ChefDK 0.2.0

[phromo]

+1 for this. My C: is tiny and does not like a 800mb install.

[epu]

User story 1:
At one time, I worked for an org where corporate policy prevented c:\ root folder installs, and users had to install things into %USERPROFILE% (which had no UAC issues for them). This profile was provided in a network drive (H:\firstname.lastname), so software you wanted to install had to be there.

User story 2:
Some users in our org have crazy fast (but smallish) SSD boot drives, that they don't want vms or large software or their internet downloads on.

[adamedx]

The standard around installing is $env:programfiles. The c:\opscode thing is not a problem for Chef and I think ChefDK should work at least as well (though I think Chef has issues if you install anywhere other than $env:systemdrive). @danielsdeleo, we can huddle with @jdmundrawala / @btm to see what's possible.
@juliandunn, your programdata idea is interesting, but definitely against the "rules" and probably somewhat dangerous. That said, if it solves the "it's illegal to create directories at the root of a volume" issue it's worth trying it out.

[danielsdeleo]

@adamedx anything with spaces is gonna be bad. It will probably work okay at first, but installing any gem with a C extension (likely to happen if a knife plugin installs/upgrades fog) is likely to blow up. Aside from that, we just need to do a little pathname magic in appbundler to handle the relative path. The code that needs to be fixed is here: https://github.com/opscode/appbundler/blob/d982fcd28f6aa234e2f24212ae15e30ee61d6b24/lib/appbundler/app.rb#L116 specifically "Kernel.load '#{bin_file}'\n" the bin_file part needs to be be relative-ized.

[adamedx]

Yeah, installer should probably forbid locations with spaces if possible. We could get fancy and try a symbolic link, otherwise I think the goal should be to make the install directory configurable with no limitation on volume and disallow spaces completely.

[danielsdeleo]

@adamedx is it possible to have conditions like that in the installer?

[juliandunn]

I know I make fun of this convention all the time, but would you still let people enter C:\PROGRA~1 as the install location?

[damphyr]

Just stumbled on this as well.
It is a very common pattern to relocate tools away from C: for Windows development, especially if we have portable versions, which is the case with 99% of OS software.

It's not a case of whether or not it's in %PROGRAMFILES% or not, it's a case of allowing usage of established patterns on this platform. And keeping C: small on Windows is a very common pattern (i.e. for a fringe usage pattern: VMs where D: is full of portable versions and project data and there is one small core C: for the OS)

A bit less common but something us obsessive/compulsive ones do is to keep the root of a drive tidy and not having it littered by all kinds of directories. So chef-dk will go under /tools etc. It took MS ages to manage that, let's not regress to the dark ages 😄

[lamont-granquist]

More evidence that supporting "Program Files" is completely out of the question right now because all the upstream ruby tooling is completely broken:

rubygems/rubygems#523 (comment)

[cheaprbytheduzn]

+1 for being able to install to alternate drives, a very common practice in our shop where C: is often out of the question.

No need to support paths with those %$#@! spaces in them. That was just a Redmond conspiracy to try to upend the *nix world. No need to cooperate with it.

[danielsdeleo]

Anyone want to try using this to regenerate the executables and tell me if it works for you? chef/appbundler#5

[tknerr]

@danielsdeleo is this included in the 0.3.2 ChefDK Release?

[danielsdeleo]

No, we needed to get the CA cert stuff fixed right away so we didn't work on any other changes. I still need to fix some tests that I broke in appbundler in that PR, and maybe get another fix into appbundler, then ship the gem and then we can start using it in Omnibus.

[tknerr]

Good to know, thanks for the quick reply!

[tknerr]

Looking into ChefDK 0.3.2 windows package I probably found some more places which are problematic. Some of them might be fixed vai opscode/app-bundler#5 already, others may not.

Here's what I found and what I'm currently working around in bills kitchen:

1. <chefdk>/bin/*.bat has the path to ruby.exe mostly fixed (i.e. "%~dp0\..\embedded\bin\ruby.exe" "%~dpn0" %*), but:

• the same-named files without the .bat extension still reference c:/opscode, e.g. ... $:.unshift "C:/opscode/chefdk/embedded/apps/test-kitchen/lib" Kernel.load 'C:/opscode/chefdk/embedded/apps/test-kitchen/bin/kitchen'
• some places still reference C:\opscode\chefdk\bin\ruby.exe (hardcoded path to c:/opscode)...
• ...along with @"%~dp0ruby.exe" "%~dpn0" %* (./ruby.exe does not exist in this dir)
• e.g. fauxhai.bat, rubocop.bat, ruby-parse.bat and ruby-rewrite.bat

2. in <chefdk>/embedded/lib/ruby/gems/2.0.0/bin/*.bat:

• all the .bat files still reference C:\opscode\chefdk\bin\ruby.exe (hardcoded path to c:/opscode)...
• ...along with @"%~dp0ruby.exe" "%~dpn0" %* (./ruby.exe does not exist in this dir)
• and I'm wondering: why do they exist anyway in here? They are just broken duplicates of the <chefdk>/bin/*.bat executables (I got them accidentally onto the PATH at some point in time and that was extremely confusing)

3. the ones in <chefdk>/embedded/bin/*.bat look all look OK for :WinNT, but still contain hardcoded paths for older windows versions (WinMe/95/98 are not :WinNT afaik), e.g.:

@ECHO OFF
IF NOT "%~f0" == "~f0" GOTO :WinNT
@"C:\opscode\chefdk\embedded\bin\ruby.exe" "C:/opscode/chefdk/embedded/bin/autospec" %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO :EOF
:WinNT
@"%~dp0ruby.exe" "%~dpn0" %*

[danielsdeleo]

A few things:

• nothing was changed in ChefDK 0.3.2, the upstream fix (here: Add relative paths support for generated bins chef/appbundler#5) hasn't been pulled into the packaging yet, so it's not expected to work. That patch fixes the hardcoded paths in the unshift lines.
• The shebang lines don't matter; when you invoke a ruby program as ruby path/to/executable the shebang is ignored, which is what the batch files do.
• The non-NT stuff comes from rubygems, which hasn't removed that code for whatever reason. We definitely don't support anything that old.
• The batch files in <chefdk>/embedded/lib/ruby/gems/2.0.0/bin/*.bat are probably generated by rubygems, I'm not sure what the purpose is exactly.

[danielsdeleo]

I've created chef/omnibus-software#334 to track getting the fix in appbundler applied to the ChefDK package.

[allnightlong]

+1 for this issue

[Ginja]

+1