Add operating system and edition checks (fixes #18) #78
Conversation
…developer mode enable scripts
|
|
|
Hi @thejsa this is pretty cool to see. Thank you. I need to loop in others from Chocolatey as I'm not familiar with the way you're version checking. This does seem like a valuable addition. Can we centralize the versioning checking logic into helper functions so the scripts can just say if (Is64Bit()) etc? |
Certainly; that seems far more elegant; I'll work on that. |
|
Complete in commit f3bad0f - haven't been able to spin up a VM to test this commit yet (will be able to once my main box is back up) but testing the scripts individually seems to yield no problems. |
|
Just throwing this out here, so people are aware of it: chocolatey also have a helper to check compare for 64/32 bit called Get-OSArchitectureWidth (The following aliases is also available: That helper can be used in two ways: if (Get-OSArchitectureWdith -Compare 64) {
# Do whatever work is needed to be done for 64bit OS's
}Or get the actual bit $bits = Get-OSArchitectureWidth # Will output either 32 or 64 depending on the architecture. |
|
Thanks for doing this @thejsa I'll test this out this week. |
| @@ -1,30 +1,39 @@ | |||
| choco install -y Microsoft-Windows-Subsystem-Linux --source="'windowsfeatures'" | |||
| if ( | |||
There was a problem hiding this comment.
A couple suggestions
- you can install WSL on some versions of Server: https://docs.microsoft.com/en-us/windows/wsl/install-on-server
- With this logic block I think it will be better to put it into a Is-WSL-Capable function in CompabitibilityChecks and use that here. Also a if !Is-WSL-Capable and return is cleaner than putting the rest of the file inside the then { }
There was a problem hiding this comment.
- Yep, this permits FCU and newer Windows Server builds to install WSL
- That certainly seems cleaner; could also allow use elsewhere for possible future dependencies on WSL. I'll do that
There was a problem hiding this comment.
(I just looked at the wsl install script, I hope I'm commenting in the right place...trying to be helpful.)
There are some gotchas on the installing the various distros, not all have a simple install options that then return you to the command prompt, thus breaking automation without some extra effort.
You can look at my Chocolatey package install scripts for examples.
https://chocolatey.org/packages/wsl-ubuntu-1804
https://chocolatey.org/packages/wsl-ubuntu-1604
https://chocolatey.org/packages/wsl-debiangnulinux
https://chocolatey.org/packages/wsl-kalilinux
https://chocolatey.org/packages/wsl-opensuse
https://chocolatey.org/packages/wsl-archlinux
https://chocolatey.org/packages/wsl-sles
Maybe distros would be better handled by choco install commands? (Yes, I'm open to improvements in my install scripts.)
There was a problem hiding this comment.
(Cross posted from #23 (comment))
I mention this because what I saw in the commit 969035c for SLES and openSUSE won't work based on my experience.
openSUSE REF: https://github.com/bcurran3/ChocolateyPackages/blob/master/wsl-opensuse/tools/ChocolateyInstall.ps1
SLES REF: https://github.com/bcurran3/ChocolateyPackages/blob/master/wsl-sles/tools/ChocolateyInstall.ps1
There was a problem hiding this comment.
Also note that WSL requires a reboot before use/installing distros.
There was a problem hiding this comment.
Thanks @bcurran3. I agree the choco install commands make it easier to install the distro. Thank you for taking initiative in making these. I'd like the distro owners to review your choco packages before we add them to this project. I'll discuss with @tara-raj and we can start going through the list of distro owners.
A challenge with installing a WSL distro as part of a boxstarter script is the default user creation so we can also automate the install of tools inside the distro. In the case of Ubuntu we use the default root user with empty password, allowing us to then automate install of packages. After the boxstarter script completes the user is encouraged to then create a new user in Ubuntu with a non-blank password. I see you do the same thing. As long as the user remembers to go in and create a user with a non-blank password and use that as the default then they're back in the same setup as when installing from the Store. It may be possible to improve on this so a choco install and Store install produce the same first run experience - this is a topic I'd love to hear feedback on from the community and distro owners.
There was a problem hiding this comment.
moving the above comment to issue #32
There was a problem hiding this comment.
@yodurr I'm game for improvements. My scripts for the installs are not the best, but the best I could do. I welcome feedback/changes/PRs. :)
| @@ -21,6 +21,8 @@ function executeScript { | |||
| iex ((new-object net.webclient).DownloadString("$helperUri/$script")) | |||
| } | |||
|
|
|||
| executeScript "CompatibilityChecks.ps1"; | |||
There was a problem hiding this comment.
what do you think of putting these include statements inside the helper scripts that use them instead of in the recipes? Since the helper scripts now have a dependency on CompatibilityChecks it would be best to add the include there or the helper scripts become more fragile.
There was a problem hiding this comment.
Hadn't thought about that (fairly new to PowerShell scripting, more used to Python) but that does make sense
Adds checks for operating system version, SKU, and architecture (where applicable) to WSL, Docker, Hyper-V, app removal, and developer mode enable scripts.