Cabal 3.4.0.0 release on Windows lacks extensions

[Mistuke]

Describe the bug

As discussed in Mistuke/CabalChoco#3 ,the binary while it doesn't need an extension for command-line execution, it does break the platform convention and is problematic in a lot of GUI based tools. a lot of tools filter the program type based on extensions.

To Reproduce

Download and unpack https://downloads.haskell.org/~cabal/cabal-install-3.4.0.0/cabal-install-3.4.0.0-x86_64-windows.zip

the file in there is cabal and not cabal.exe

Expected behavior
I expect file to be cabal.exe

System information

• Windows (all)
• cabal: 3.4.0.0

Additional context

Currently blocking packaging of cabal on chocolatey and haskell-ci

haskell/actions#39

[phadej]

To fix, we need to change

cabal/release.py

Line 255 in 89df281

shutil.copy(cabal_path, rootdir / 'cabal')

and repackage.

[jneira]

I am afraid that i observed that in the release candidates downloads but i assumed the official release download would be done in other way (the same way previous correct ones) 😟

[phadej]

@jneira Release candidates where there so people could report issues, also about packaging.

I was testing new packaging scripts as well.

I think I shouldn't have assumed that people would report issues about that. But you shouldn't assumed either. Let's not assume anything and ask if something doesn't seem right, ok?

[jneira]

Sure, I have to say that if RC downloads had been placed in the same page or site than the official one I would be more inclined to open an issue or mention it.
Otoh I am watching loosely issues and pr's in the repo and did not read anything about changes in packaging (windows or generic), sure I missed just the relevant pr

[bgamari]

In addition to the missing extension, the file naming of the distributions themselves has changed. Perhaps this was intentional but in my opinion it's best to name distributions with a proper triple and only deviate with good reasons. Afterall, there are untold many scripts which depend upon this naming convention.

[bgamari]

In addition to the missing extension, the file naming of the distributions themselves has changed. Perhaps this was intentional but in my opinion it's best to name distributions with a proper triple and only deviate with good reasons. Afterall, there are untold many scripts which depend upon this naming convention.

Investigating a bit more closely, it looks like these names come from release.py. Frankly, this seems pretty reasonable to me. We could populate the old names with symlinks as a transitional measure if that is desirable.

[emilypi]

One more thing to track raised by a Windows user: https://mail.haskell.org/pipermail/haskell-cafe/2021-February/133465.html

Apparently we're not testing cabal-install on Windows + GHC 8.10? What gives!?

[Mistuke]

Apparently we're not testing cabal-install on Windows + GHC 8.10? What gives!?

That's just windns requiring a version bound update for cabal 3.4.0.0, nothing new, maintainer just hasn't gotten to it yet. You can easily work around it with --allow-newer

[emilypi]

@Mistuke alright that explains the CI passing for windows. I got @mightybyte to do a bounds bump

[emilypi]

@Mistuke so this should be fixed. Are you good on your end?

[RyanGlScott]

I'm confused:

• The relevant line of release.py hasn't changed, either on the master branch or on the 3.4 branch.
• Moreover, the Windows bindist here still lacks an .exe extension.

In what sense has this issue been fixed?

[emilypi]

@RyanGlScott

Moreover, the Windows bindist here still lacks an .exe extension.

Are we seeing the same thing here? Ben Gamari and I uploaded a revised version on sunday that had the correct extension. I just downloaded and it had cabal.exe in the archive.

The relevant line of release.py hasn't changed, either on the master branch or on the 3.4 branch.

This can be addressed later, and we're not even sure this is a change that needs to happen, since it's probably more correct as @bgamari mentions. I need to know if Mistuke is unblocked on the binaries now, which is the more pressing issue.

[RyanGlScott]

Are we seeing the same thing here?

Perhaps not! I tried downloading https://downloads.haskell.org/cabal/cabal-install-3.4.0.0/cabal-install-3.4.0.0-x86_64-windows.zip this morning, which contained cabal (without an .exe extension) at the time. But now that I've tried again just now, it indeed contains cabal.exe! How strange.

[emilypi]

downloads.haskell.org aggressively caches everything, so who knows lol. Either way, that should fix Chocolatey for now, and we can talk release.py.

Now, i'm fine with naming changes as long we shout them loudly. This particular issue is the result of not doing that and letting everyone else clean up when things broke. I'm fine with the change to convention though! If @Mistuke/other people tell me otherwise that it's a PITA or breaks some system invariant, I'll throw a PR up for reverting that behavior.

That said, @fgaz and I are currently the only active maintainers, so any help people can contribute is very appreciated.

[Mistuke]

@emilypi yup, we're all good, thanks! package is making it's way out so I can publish GHC 9.0 :)

[emilypi]

great! glad we could get you unblocked @Mistuke and sorry for the confusion 🙇

[jneira]

Sorry if this is not the appropriate issue (happy to open a new one if needed) but I usually downloaded the official release from
https://www.haskell.org/cabal/download.html
but it still links to the 3.2 version for me

It would be great if release candidates would be listed there too (or link to other dedicated page within haskell.org).

I think it would help it's diffusion, so more users would try them and more errors would be catched.

[emilypi]

@jneira that's something we'll have to poke the haskell org folks to update. Submit a PR with an update to https://github.com/haskell-infra/www.haskell.org and I'll approve + merge it (i still have rights!)

[gbaz]

can this be closed?

[emilypi]

@gbaz i'm not sure we want to close it until there's a PR to release.py. If it hasn't happened, this issue should be linked to that request.

[jneira]

afaics https://downloads.haskell.org/~cabal/cabal-install-3.4.0.0/cabal-install-3.4.0.0-x86_64-windows.zip is fixed and release.py does not exist anymore so i think we can safely close this

[Mikolaj]

I'm afraid the Windows build at https://downloads.haskell.org/~cabal/cabal-install-3.8.1.0-rc1/ has no .exe, so I'm reopening.

@hasufell: would it be possible to get .exe by tweaking the gitlab CI script or does it require changes elsewhere?

[hasufell]

I'm afraid the Windows build at https://downloads.haskell.org/~cabal/cabal-install-3.8.1.0-rc1/ has no .exe, so I'm reopening.

@hasufell: would it be possible to get .exe by tweaking the gitlab CI script or does it require changes elsewhere?

It's a zip file https://downloads.haskell.org/~cabal/cabal-install-3.8.1.0-rc1/cabal-install-3.8.0.20220526-x86_64-windows.zip

Did you look inside?

[Mikolaj]

Did you look inside?

Yes, that's how I know the file is cabal and not cabal.exe.

[Mikolaj]

*the file inside

[Mikolaj]

Copied from #7297

https://gitlab.haskell.org/haskell/cabal/-/blob/master/.gitlab/ci.sh#L64

that would probably need to be special-cased for 1MSYS_|MINGW1 to be "$CI_PROJECT_DIR/out/cabal.exe"

[Mikolaj]

This should be fixed in 3.8.1.0-final (or 3.8.1.0-rc2) thanks to #8191. Please confirm once it releases in a month or so.