Document install process on mono

[TheCakeIsNaOH]

Currently, there is no documentation that I can find on how to install Chocolatey on a Linux/Mac OS system with mono.

The current best process as I see it-

1. Build via build.sh
2. Copy or link the contents of the ./code_drop/chocolatey/console directory to your preferred install path
3. Copy the choco_wrapper in the docker directory to a folder that is on your $PATH and rename to choco. The docker container copies it to /usr/local/bin/
   3a. Modify the path in the choco wrapper if your install is different from the default /usr/local/bin/chocolatey
4. Export the ChocolateyInstall environment variable to point to your install path.

I think the exact paths to use is up for discussion, although moving to /opt/chocolatey as the install path is probably a good option. This is because chocolatey is currently an add on software package that is not installed through a package manager. See the Linux filesystem hierarchy for more information.

[zlesnr]

Yes please. Going through this now, though using docker on a mac, since the mono brew version is 6, rather than what's in the travis file for build.

The following seems to work, but the resulting exe complains because the version is not known.

git clone [email protected]:chocolatey/choco.git ~/src/choco
docker run -t -w /mnt -v ~/src/choco/:/mnt mono:5 ./build.sh

Though, I get confused when I try to execute it from the OSX to create a new pacakge.

mono build_output/chocolatey/choco.exe --allow-unofficial new testeroo
Chocolatey v0
Directory 'C:/ProgramData/Chocolatey/lib' does not exist.

[TheCakeIsNaOH]

The version not getting set when building in docker is a known issue. I have PR #2024 open to fix it.

For the lib directory does not exist error, try defining the chocolatey install variable-
export ChocolateyInstall=~/src/choco/code_drop/chocolatey or similar, I am not sure if ~ works in environment variables on mac, you may need an absolute path.
Then run via mono ~/src/choco/code_drop/chocolatey/console/choco.exe --allow-unofficial new testeroo

[zlesnr]

Thanks for the information. Looking forward to this. Not sure if ~ is available, just used it for brevity.

[TheCakeIsNaOH]

For anyone running into this, here are a list of the current issues I know about:

• If the nupkg already exists, choco pack can fail: choco pack command fails on non-Windows when the nupkg already exists #2076
• (FIXED) In files element of a nuspec, if the path separator is incorrect (ie a \), it will not include the files: Ensure correct path separator in nuspec files is used on different operating systems #502; (GH-502) Correct path separator in nuspec file element nuget-chocolatey#19
• There can be issues with choco finding the install location correctly: See next comment.
• (FIXED) If the files element of the nuspec is completely missing, it will not include any files inside the nupkg: https://github.com/chocolatey/choco/issues/2212; (#2258) Linux pack all files if no files element in nuspec nuget-chocolatey#21
• (FIXED) On systems with a merged usr, the a test will fail due to a hard coded path: Mono build test failure on systems with a merged usr #2236

[AdmiringWorm]

There can be issues with choco finding the install location correctly, I haven't tracked it down enough to make an issue yet.

Most likely, it is due to choco trimming the start of the CodeBase value when checking for paths.
Basically, it removes the first instance of file:///.

on Windows, it is fine, where the path would be something similar to:

file:///c:/ProgramData/Chocolatey

but not on Linux (I don't know about OSX), where the path would be:

file:///opt/chocolatey

by removing file:/// from the path changes the absolute URL to a relative URL and causing problems with not finding specific directories/files (like Chocolatey's own lib dir, for instance).

additional note, on Linux a path using the file protocol can also be in the format:

file://localhost/opt/chocolatey

Although, I haven't seen that happen for the CodeBase parameter.

See the following patch for the updates I did to make it work: https://github.com/AdmiringWorm/chocolatey-arch/blob/master/0002-Don-t-replace-prefixed-slash-on-unix-systems.patch (not contributed, as it needs more testing to make sure).

[TheCakeIsNaOH]

Thanks for the write-up, I gathered as about as much from the patch, but wasn't sure of the specifics.

Could this also cause problems over in the DotNetFilesystem? As it also does a CodeBase.Replace("file:///", string.Empty)

https://github.com/chocolatey/choco/blob/master/src/chocolatey/infrastructure/filesystem/DotNetFileSystem.cs#L178

[AdmiringWorm]

@TheCakeIsNaOH yes, which is why I also patch that one in the patch: https://github.com/AdmiringWorm/chocolatey-arch/blob/master/0002-Don-t-replace-prefixed-slash-on-unix-systems.patch#L57

Basically, the files ApplicationParameters and DotNetFileSystem are affected. There could be other places as well, but those two are the ones I noticed.

There is also a similar issue with the NugetPack class regarding the filter, which I believe is only valid for nuspec files not specifying a <file /> element (but I could be wrong).

[TheCakeIsNaOH]

Ok, sorry about that, I completely skipped over that it also patched that file.

[hurricanehrndz]

There can be issues with choco finding the install location correctly, I haven't tracked it down enough to make an issue yet.

Most likely, it is due to choco trimming the start of the CodeBase value when checking for paths.
Basically, it removes the first instance of file:///.

on Windows, it is fine, where the path would be something similar to:

file:///c:/ProgramData/Chocolatey

but not on Linux (I don't know about OSX), where the path would be:

file:///opt/chocolatey

by removing file:/// from the path changes the absolute URL to a relative URL and causing problems with not finding specific directories/files (like Chocolatey's own lib dir, for instance).

additional note, on Linux a path using the file protocol can also be in the format:

file://localhost/opt/chocolatey

Although, I haven't seen that happen for the CodeBase parameter.

See the following patch for the updates I did to make it work: https://github.com/AdmiringWorm/chocolatey-arch/blob/master/0002-Don-t-replace-prefixed-slash-on-unix-systems.patch (not contributed, as it needs more testing to make sure).

Is this what leads to:
choco unpackself
Chocolatey v0.10.16-beta-163-g5868c66a
Directory 'C:/ProgramData/Chocolatey/lib' does not exist.

[AdmiringWorm]

@hurricanehrndz yes, from my testing that is indeed (at least part of) the reason for the warning message.