Support for cache directory

[fekir]

Hello,

I've used with success your Project, for downloading Chocolatey Packages.
My problem was that I have some computers on a different network wihtout an internet connection, so I had to copy the download folder from one server to another. Chocolatey was unable to upgrade the packages since the PATH in the .ps1 scripts was not right anymore.

This is why I added a third (optional) parameter to specify a "cache directory", where ChocolateStore is going to download all the files, but the path used in the .ps1 files is still going to be the directory path.

[BahKoo]

Thanks for your interest in the project and for your pull request. I will review the commits next week and consider merging it.

[BahKoo]

Hi fekir,

I reviewed your code and everything appears to work for your use case. I found that using 2 paths was a little confusing because it's hard to describe what the paths mean. I thought about the problem a little more and came up with an alternate solution which I checked into the relative-path branch.

I added an option to save relative paths instead of absolute paths. This makes the entire "store" portable and allows you to move it to a new file path or a new computer. The only downside is that you must run cinst from the "store" directory for the relative paths to work. Could you look at this solution and compare it to yours? Would this solution meet your needs?

Thanks

[fekir]

Hi, thank you for your time.

I'll be able to test it during this weekend, it may do the work, but having to run cinst from the store is far less than ideal.

My problem is that I would like to use Chocolatey on a PC without an Internet connection.
With my patch I'm able to set an absolute path that does not exist on the computer that has an Internet connection. After downloading the files with ChocolateStore I copy the file on an internal server, and added the source to my Chocolatey installation. In this case there is no need to run cinst or choco upgrade from a specific folder.

Your solution is less than ideal because I should cd on the server. It's possible, but not that great.

Maybe the best solution, to avoid confusions between the two paths, would be to have a download command, that works like your original project, and a "change store command" that updates the path of all scripts to a given path. What do you think?
In that case, if you have downloaded some big packages (like libreoffice) and didn't notice that you where in the wrong directory, you don't need to download them again.

[BahKoo]

There's no need to test my solution if you feel the compromise of needing to run cinst from the store folder isn't worth it for the portability of the store.

I understand your scenario but I feel it may be an uncommon one. The reason I'm hesitant to merge your solution is because it can leave the resulting store in an unusable state until you move it to a machine that has the proper folder structure. I think this could lead to confusion about the purpose and proper use of this feature.

I like your idea about having a second command for changing the store path. It decouples changing paths from downloading. The store path can be changed multiple times without re-downloading (like my solution) and it allows cinst to be ran from anywhere (like your solution).

[sr258]

A possibly common application for this feature could be if ChocolateStore runs on a linux machine with Mono. The usual \\Share\directory paths won't work there when the files are being downloaded, but this format is still required for the Windows clients.

The best way to approach all these issues, though, might be to put the downloaded files into the nuget packages themselves. That way there aren't involved any absolute paths at all.