[Documentation] Package installation guideline in Create Packages

[FunkMonkey]

I think the Create Packages should contain a section about installation paths, advising the package owner to

a) state the default installation path of the package in the package description b) (if possible) explain how to change the installation path in the package description

Also instructions for the owner to allow custom installation paths (if possible) should be found in the Create Packages page as well, as it is an important topic.

It happened to me a couple of times already, that packages clutter up my filesystem root under C:\ (like ruby and git.commandline) without giving me a warning upfront (f. ex. in the description).

This bug is connected to bug #32.

p.s. I didn't know if I could just added the wiki page, but I at least wanted to get permission

[ferventcoder]

You can add to the wiki page... please mention the binroot for packages - we have the concept of having some packages install to another directory if someone defines an environment variable.

[ferventcoder]

And it should be mentioned that if you want to override the default installation, just add to the installation arguments the correct switch and location for the particular native installer - jhttps://github.com/chocolatey/chocolatey/wiki/CommandsInstall

The important part is that you need to be intimate enough with the package to know this...

[FunkMonkey]

We should probably also move the "What distinction does chocolatey make between an application and a tool?" from the FAQ into the new "Installation Paths" section of Create Packages - as it seems to belong there.

Before I start editing, I have some minor questions though.

I understand that some packages use "chocolatey_bin_root" for installation paths.

For other packages you seem to be able to pass -installArgs. Can the end-user pass -installArgs from cinst or does the developer pass -installArgs to the Install-ChocolateyPackage ($env:chocolateyInstallArguments) in the chocolateyInstall.ps1? Can the developer use the "chocolatey_bin_root" for passing it on to the setup.msi file? Is that recommended?

Also, some packages like Console2 do not seem use any install helper in their chocolateyInstall.ps1. I checked the package repo and it already seems to include the application files in the "bin" folder (so nothing is downloaded from the original vendor). Is this what is described as a "tool" in the FAQ? Is it valid to deliver a package like this or is it clearly discouraged? It definitely introduces one more installation path behaviour.

Should the general advice for package developers be to adhere to "chocolatey_bin_root"? should there be different advice for apps and tools? Just sticking to "chocolatey_bin_root" (no matter if extracted from zip or installed from msi [when the msi allows custom installation paths]) would clearly reduce the installation path problem

These are a lot questions, but I think we could really improve the documentation if we'd clearly state what is possible and recommended concerning installation paths.

Thanks.

[ferventcoder]

Lots of questions in here.

I would point to the FAQ question from the create packages page - and maybe put a little blurb that highlights the difference. It is definitely an asked question, and frequently. :)

There is a push for an Install-ChocolateyTool function - in that function it would look up the binRoot (or whatever we call it once it is in chocolatey).

Console2 is a tool (no native installer). But there are other ways to get tools - which download the archived version (.zip, .7z, .tar) and then unpack it to somewhere. Lots of these just unpack it into the package folder itself, which allows the executables to be found by chocolatey and put on the path.

As far as MSIs and native installers - the person who wrote these had in mind a location for the application to install to (in program files). This IMHO should stay the default. I know the argument can be made that there are some packages that don't, but this is due to the littering of the systemdrive with installs. Usually MSIs are easier to work with since 99% of the time they have the same installation switches, one of which is the install location.

The general idea behind chocolatey is to move to less and less work being required in the chocolateyInstall.ps1. We want to address patterns and make that easier so that one can just call one line functions. You can see there are a lot of packages that already go that route (if they are just pulling in an application).

[ferventcoder]

One thing we will likely do in the future is allow folks to pass in the installer type (NSIS, InstallShield, etc). Then we can make assumptions on some of the switches. This is closer to what I saw chef was starting to do in their default provider for windows. I also saw it in another package manager that is now defunct.