Paul Broadwith

> Can our Chocolatey installer tell if it's a clean install or an upgrade? You can simply detect if the module exists as a loadable module or not. But you'll...

> For reference, here's Invoke-Build's Chocolatey tools. That package installs globally, but I'd be inclined to install to ($Env:PSModulePath -split ';')[0] (which is ~\Documents\WindowsPowerShell\Modules on my machine). In the case...

> For v1.0 I'm strongly considering adding PowerShell 5+ as a Chocolatey dependency, and having the install/uninstall scripts just delegate to PowerShellGet using the PowerShell Gallery. Thoughts? I wouldn't add...

@bergmeister Chocolatey needs to run elevated so it can install packages. It would be difficult to scope a package installation to the current user. There are ways to do it...

That's cool. Chocolatey is still something new to a lot of people - but you should check it out :) It does reinvent the wheel a little insomuch as we...

> Not non-developers. Non-PowerShell developers. People who use PowerShell as a shell (often for posh-git, often from GitHub for Windows initially), but have never written a script or module themselves....

> I see Chocolatey very much as the "just get this working, I don't really care how" option. I disagree entirely. As a Chocolatey user I very much care 'how'.

> I don't mean to; it's not a matter of "can". But this is the first I can recall in seven years as a Chocolatey package that someone has objected...

> Right. My point is that they don't need to know as long as it works. I respectfully disagree. You need to let them know what you're doing as modifying...

> With respect, you're thinking from a PowerShell Module standpoint, not a Chocolatey "application" standpoint. Application installers nearly always change their environment on install, otherwise $Env:PATH would never get modified....