Ability to use Get-ChocolateyUnzip with "Extract"[e] instead of "eXtract with full paths"[x] -- 7z (cmd)

[n3rd4i]

Current situation when using Get-ChocolateyUnzip the 7z command that gets executed is "x":

• 7z.exe x which means "eXtract with full paths"
  Ability to change this to "e" could be beneficial for download/zip files which contain folders and only files (not folders) from the archive are needed, example:
• 7z.exe e which means "Extract"

I could not find workaround this issue.

One could try to use move commands after unzip but that defeats the intended functionality?

[ferventcoder]

Not sure I follow all of this. Extract with full paths basically ensures the file structure of what is zipped up. If you wanted it without file structure, why not put it into the zip that way?

[n3rd4i]

Problem is that not me is doing that, this is how the package is set up by Upstream if you want to call it that.

For example I'm creating SW package based on 3 components:

1. Component Support pinning #1: a zip package which has some files inside and an *.exe
2. Component Support switching shims between multiple installed versions #2: another zip file which has a folder inside and some files inside that folder
3. Last component Support regenerating shims #3: which has same situation as Support pinning #1

Because the Install-ChocolateyZipPackage currently uses Get-ChocolateyUnzip which in place uses hardcoded 7zip command from which only 7z.exe x is supported I could not find easy way to flat-out the upstream package:

E.g.:

$params = "x -aoa -bd -bb1 -o`"$destinationNoRedirection`" -y `"$fileFullPathNoRedirection`""

IMO it could beneficial if there is a way to "flat-out" some zipped content so that user could do that. Currently I need to do workaround for this like:

Install-ChocolateyZipPackage @UnZipPackageArgs
& Move-Item -force $installLocation/ZIP_FOLDER/*.fileExt $installLocation/
& Remove-Item $installLocation/ZIP_FOLDER

[bcurran3]

You can run "&$ENV:ChocolateyInstall\tools\7z.exe e ZIPFILE"

[ferventcoder]

@bcurran3 that is not considered part of the public API. So it's likely we will move those things and it will break packages using these internal things. In other words, please refrain from assuming these things will be here, and absolutely do not use them directly.

[ferventcoder]

So it sounds like we need to expose a flatten parameter?

[bcurran3]

@n3rd4i - you can also use 7zip.commandline as a dependency to solve this problem. (The shim will make you happy.)

Using my previous method, you'd want to put a dependency of chocolatey and limit it's version through the current beta to be safe.

@ferventcoder - I understand that things (Chocolatey install method) could change...

1. Are there PLANNED changes?
2. We've bumped into the topic of "public API" a few times. Where is it published? The only thing I've ever found is helper functions that say they aren't part of the public API. Are you talking about choco.dll or do you refer to the Chocolatey helper functions as an "API?"

[ferventcoder]

This is the API - https://chocolatey.org/docs/helpers-reference. If you don't see it here, don't use it as it is not part of the published API.

[ferventcoder]

Basically the only contracts for Chocolatey provided things that change slowly and with long term compatibility are the Chocolatey functions, unless a function specifically states it is not part of the public API and should not be used directly (as you pointed out).

[ferventcoder]

1. Are there PLANNED changes?

Not at this time, but you wouldn't want something to break if we did. We have moved things in that area in the past and it did break things for some package authors. We warned them against it as well when we saw they were doing it. Just to remind myself to keep folks on the right track, I've added this chocolatey/package-validator#189. Better to know right off you are not following a best practice and stick to what's available - and request for enhancements here, like @n3rd4i has done.

you can also use 7zip.commandline as a dependency to solve this problem.

I definitely like this aspect, as it is more flexible until Chocolatey can support it.

[AdmiringWorm]

you can also use 7zip.commandline as a dependency to solve this problem.

Just an FYI, do not use the 7zip.commandline package, this package have been deprecated for 2 years now. Instead, use the 7zip.portable package instead.