Support for cabal-3.4

[newhoggy]

Can we have support for cabal-3.4 release candidate?

I can see cabal-3.4.0.0-rc3 listed, but it seems broken:

https://gist.github.com/choco-bot/3c4b83125a8bae73d1aecd195aa10e27

[newhoggy]

More specifically I see this error:

2020-10-01 16:04:45,708 1400 [ERROR] - ERROR: The term 'Write-Information' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
 at ReadCabal-Config, C:\ProgramData\chocolatey\lib\cabal\tools\chocolateyInstall.ps1: line 198
at Configure-Cabal, C:\ProgramData\chocolatey\lib\cabal\tools\chocolateyInstall.ps1: line 267
at <ScriptBlock>, C:\ProgramData\chocolatey\lib\cabal\tools\chocolateyInstall.ps1: line 379
at <ScriptBlock>, C:\ProgramData\chocolatey\helpers\chocolateyScriptRunner.ps1: line 49
at <ScriptBlock>, <No file>: line 1

[Mistuke]

That means you're running a severely out of date version of powershell. Should only happen on systems that have not been running windows updates such as the choco bot VM.

I will patch the installer but don't intend to support pre-powershell 5 in any official capacity.

[Mistuke]

It is curious though as the packaging didn't change between 3.2 and 3.4.. I'll need to look a bit more into why it's hitting this codepath.

[newhoggy]

The above error happens on Github Actions, which is a quite widely used CI system.

Perhaps it would be useful to create a Github Action workflow to CI test the choco installer script.

I can help with that if you're interested.

[Mistuke]

I submitted https://chocolatey.org/packages/cabal/3.4.0.1-rc3 which should fix this. There was a slight change of semantics in cabal-install that caused a different error code to be produced and hence it was using this code path. This was really only an issue on older powershell as mentioned above. I have removed the use of the newer CmdLets.

Perhaps it would be useful to create a Github Action workflow to CI test the choco installer script.

Not sure how much that would help as I don't look at the github repository at all aside for bug reports. Packages are released by my internal CI which checks for configuration expected on a typical user machine.

As you noted above it also failed chocolatey verification since they too use windows server 2013, but since it's a pre-release package it isn't required to pass. An actual release would have triggered an action for me to look at.

[Mistuke]

it's passed verification, so should be available.

[newhoggy]

Thanks!

[newhoggy]

Is it possible to publish it as 3.4.0.0-rc3?

Tools like https://github.com/haskell/actions use the version number to construct the path to the binary, which means they can't find the binary because of the version number mismatch:

For example, it looks in:

C:\ProgramData\chocolatey\lib\cabal.3.4.0.1-rc3\tools\cabal-3.4.0.1\

When it actually is in:

C:\ProgramData\chocolatey\lib\cabal.3.4.0.1-rc3\tools\cabal-3.4.0.0\

[newhoggy]

If it's not possible to republish it as 3.4.0.0-rc3, then something like 3.4.0.0-rc3-1 is preferable in order to retain the same cabal version number.

[Mistuke]

Is it possible to publish it as 3.4.0.0-rc3?

Unfortunately no, packages are immutable.

Tools like https://github.com/haskell/actions use the version number to construct the path to the binary, which means they can't find the binary because of the version number mismatch:

They are bypassing the package's own ability to register itself, which means that github actions has to deal with the versioning scheme being used. The build number, the same as the GHC package is used to iterate on the package not the cabal binary version.

Since the package is being bypasses all versions with the same major, minor and revision number to the same thing regardless of the build number.

The very fact this is needed is because github actions has a funky setup to begin with... The cabal package shouldn't need the PATH to be set as it uses chocolatey's default registration method which creates a symlink to the same folder that choco itself is installed to. So if choco is on the PATH so should cabal and in fact this works on every user machine and other CI systems BUT github actions.

If it's not possible to republish it as 3.4.0.0-rc3, then something like 3.4.0.0-rc3-1 is preferable in order to retain the same cabal version number.

When the package is not an rc this versioning scheme becomes invalid, 3.4.0.0-1 is an invalid version according to the NuGet versioning scheme. This is why the package increases the build number instead, which is also what chocolatey recommends.

Unfortunately cabal always releases using a 4 component version, even though they never change build.

In the mean time I have build and release rc5 but the scheme needs to be dealt with.

[Mistuke]

Also... By bypassing the package's detection of github actions it also means the package won't configure cabal specifically for it. You have to do stuff like setting a store-dir path yourself... and any other configuration I add in the future. So I don't recommend this approach.

If you really must... Instead of setting the PATH to the install folder you could instead set the PATH to chocolatey's symlink folder which doesn't change per package. The Cabal package doesn't support side by side installs anyway.

[Mistuke]

That said, I think long term we need to resolve what the package should do on github actions. As I mentioned just overriding the detection is just gonna lead to issues down the road..

So we need to find something that works for both uses of the actions package and those using it without. Any suggestions @newhoggy ?