cabal init fails if folder name exists on hackage

[menelaos]

Describe the bug

If cabal init is run inside a folder that has the same name as a package on hackage, cabal throws an error: Error: no package name provided.

To Reproduce

mkdir lens
cd lens
cabal init

This also happens for a hidden folder (.lens).

It does not happen if the folder name does not exist on hackage:

mkdir doesnotexistonhackage
cd doesnotexistonhackage
cabal init

Expected behavior
I would except cabal to at least give a more precise error message or better proceed with only a warning.

System information

• cabal-install version 3.0.0.0

[naglalakk]

I second this. I just got this error as well and it's very confusing and gives no indication of what is actually going on

[codygman]

I was just bit by this one and if I hadn't found the issue googling it could have wasted a bit of time.

[hvr]

This appears to be a regression; previously cabal init would complain to you about this during the interactive questionnaire:

This package name is already used by another package on hackage. Do you want to choose a different name? [default: y] 

[fgaz]

@emilypi #7344 fixes this, right?

[jneira]

i would close it when the mentioned pr is released

[gbaz]

As a general practice I would recommend closing tickets when the prs resolving them are merged, not when a cabal with the pr merged is actually released. It makes ticket management much saner.

[jneira]

As a general practice I would recommend closing tickets when the prs resolving them are merged, not when a cabal with the pr merged is actually released. It makes ticket management much saner.

Yeah, i forgot we have milestones here to signal the issue is fixed for some release

[emilypi]

This was fixed in #7344 yes

[weihsiu]

this error is back. using cabal-install version 3.6.2.0

[Mikolaj]

Hi @weihsiu,

I think we had a wrong milestone set, suggesting the fix has been merged to 3.6.2, while it's slated for 3.8.

Could you perhaps try with the master branch?

[weihsiu]

np, i just wanted to report the issue. as long as it will be fixed, i am cool.

[rkuprov]

The issue is alive as of 2023.03.10

[ulysses4ever]

@rkuprov what version of cabal are you using?

[rkuprov]

cabal --version cabal-install version 3.6.2.0 compiled using version 3.6.2.0 of the Cabal library

[rkuprov]

Had to do the init --interactive and force ignore the warning about the package already present on Hackage.

[emilypi]

@rkuprov use a version of cabal that was released in the last 2 years and you'll be set.

[rkuprov]

My bad. I wrongly assumed that GHCup would use everything latest.

[ulysses4ever]

@rkuprov unfortunately, ghcup has its own notion of recommended release, which it uses to pick default versions, and the lead maintainer @hasufell explicitly refused to bump recommended cabal to 3.8 citing several regressions on 3.8. In my opinion, there were many more bug fixes in that release that justify a handful of regression, but oh well...

[hasufell]

Correct. GHCup is a distribution channel just like nixpkgs, brew or some ubuntu ppa. As such it has absolute autonomy regarding which versions are recommended.

To always and only get upstream bindists, you can use a different channel: https://github.com/haskell/ghcup-metadata/blob/develop/ghcup-vanilla-0.0.7.yaml

In this channel I can make latest and recommended equivalent, but we will close bug reports as WONTFIX if you use that channel.

Check out the configuration: https://github.com/haskell/ghcup-hs/blob/c20deceaa8189a1f3034335759b84132f9a9ef82/data/config.yaml#L59