Choco: Add an option to remove the compressed file after having used Get-ChocolateyUnzip

[chtof]

When using Get-ChocolateyUnzip, compressed file remains on the system if we don't delete it.

So, today, we have to use something like:

Get-ChocolateyUnzip @packageArgs
Remove-Item -Path $packageArgs.file

It should be nice to have only a command like:
Get-ChocolateyUnzip -RemoveZipFile @packageArgs

Or maybe to remove by default the compressed file but of course, in that case, we should be sure any side effects can occurs on existing scripts.

[ferventcoder]

I think being able to distinctly choose to remove it is the right thing. The script is just PowerShell after all, so it makes sense to call Remove-Item here.

Thoughts?

[vexx32]

This wouldn't remove the choice, only make it simpler to do. Add a switch vs an entirely separate cmdlet.

However, PS tends to recommend a one-purpose-per-cmdlet paradigm, so there may be value in maintaining the separation, if only for semantic clarity.

[pauby]

I'd agree with @ferventcoder - to remove the file is a simple case of Remote-Item and I've seen many packages do that.

The name Get-ChocolateyUnzip is clear in what it does and as @vexx32 says a cmdlet / function should do one thing.

[vexx32]

@pauby while tangential to the issue at hand, Get isn't really the appropriate verb there, I don't think. It's sufficiently clear in appropriate context, but outside that I'd _really_ be guessing as to what the expected behaviour is.

Something like Expand-ChocolateyArchive or something might be more appropriate; the callback to the original Expand-Archive cmdlet seems more effective to me. 🤷‍♂

[ferventcoder]

I would agree the naming is terrible on the name. I don't think expand was one of the approved verbs 8+ years ago. We can move to other things, but we need to keep the bad name as an alias as we do for longer term compat.

A good way of visualizing this is Get-ToolsLocation https://github.com/chocolatey/choco/blob/c57829c325e95c99b553a0e26e7d7aac8e233725/src/chocolatey.resources/helpers/functions/Get-ToolsLocation.ps1#L97

[ferventcoder]

Maybe we should write up issues on better naming the functions.

[chtof]

For me, it's easier to remember that almost chocolatey commands starts with Get, Install, Uninstall, Write.

[vexx32]

Sounds good! I'd also recommend keeping aliases in the function definitions rather than using Set-Alias. Easier to maintain. For example:

function Expand-ChocolateyArchive {
    [CmdletBinding()]
    [Alias('Get-ChocolateyUnzip')]
    param( ... )
    ...
}

@chtof as @ferventcoder mentions you are more than welcome to keep using the old names an your preferred alias ^^

[chtof]

To make it simpler, what is the problem to add an option to the Get-ChocolateyUnzip command to remove automatically the zip files once the file are uncompressed?

[pauby]

@vexx32 Yeah, it's probably clear to me as I've been using it for so long. Part of that is it's big (or little) brother Install-ChocolateyZipPackage which does something similar but downloads first.

I agree with both you and @ferventcoder that there are probably better verbs to use than Get now and Expand is the only real choice.

[chtof]

And to facilite the comprehension of a chocolatey script by another maintainer, I am not sure it's a good idea to use aliases.

[pauby]

@ferventcoder

Maybe we should write up issues on better naming the functions.

Agreed. While we are doing that I think delving into using consistent / standard parameter naming would be something that would be helpful?

[ferventcoder]

[Alias('Get-ChocolateyUnzip')]

This doesn't work in PowerShell v2. That's why it is done this way. We must maintain compat with PowerShell v2 until sometime after January 2020.

[pauby]

We must maintain compat with PowerShell v2 until sometime after January 2020.

We could just wait until after January 2020 before starting this? I don't think there is any hurry on implementing new names?

[ferventcoder]

We still need the names and it is sometime AFTER January 2020. It's not set on when that would be. I don't know when the aliases started working this way, but I think it was PowerShell 4 or 5.

[chtof]

@Pauby I agree if we don't abuse in the number of alias name. More command names Chocolatey will have, harder it will be to memorize and recognize all commands, especially for non-english speaking users.

[vexx32]

PS V3 from memory, but we could look that up. :)

[pauby]

I agree if we don't abuse in the number of alias name. More command name Chocolatey will have, harder it will be to memorize and recognize all commands, especially for non-english users

@chtof The intention is not to increase the name of cmdlets. The intention is to rename them and provide aliases for backwards compatibility. I agree that it is a new set of cmdlet names going forward however.

[ferventcoder]

Could be - I know we were bitten on that in SMA only in v5+. https://www.kickstarter.com/projects/ferventcoder/chocolatey-the-alternative-windows-store-like-yum/posts/1484093

[chtof]

Also, to make it simpler, it should be nice to have shortcutFilePath, shortcutTargetPath and shortcutOptions options to commands like Get-ChocolateyUnzip and Install-ChocolateyZipPackage (and maybe others one) in order to use easily these options in packageArgs array variable instead of having to add something like:

# Install start menu shortcut
$programs = [environment]::GetFolderPath([environment+specialfolder]::Programs)
$shortcutFilePath = Join-Path $programs "InfiniTex.lnk"
$targetPath = Join-Path $toolsDir "InfiniTex-0.9.16.exe"
Install-ChocolateyShortcut -shortcutFilePath $shortcutFilePath -targetPath $targetPath

Also, shortcutFilePath would be deleted automatically during uninstall (so for almost cases, an uninstall file would be useless or lightened).

[ferventcoder]

@chtof sounds like a good feature request that is deserving of its own ticket. There may even already be an existing ticket. Best to separate it from here.