Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

cabal-install should treat package names case insenitively in the UI wherever possible #160

Closed
bos opened this Issue May 24, 2012 · 6 comments

Comments

Projects
None yet
1 participant
Contributor

bos commented May 24, 2012

(Imported from Trac #167, reported by @dcoutts on 2007-11-01)

Currently saying cabal list haxml works fine and returns hits for HaXml which is good. The same does not apply when it comes to cabal install haxml. So what it should do is to look case-insnesitively for haxml. If the match is not exact case-sensitively and there are more than one packages matching case-insensitively then it should abort with a message listing the matches. This should not often happen since within any single HackageDB server, we check that packages names are unique case-insensitively but it's possible to get ambiguities if cabal-install has been configured to use multiple repos.

Contributor

bos commented May 24, 2012

(Imported comment by guest on 2007-11-01)

I was under the impression we'd agreed that package names are case insensitive, but that doesn't seem to be written in the obvious place in the Cabal docs. Anyway, I think that foo-1.0 in one hackage and FOO-2.0 in another should be taken to be different versions of the same package.

-- Ian Lynagh

Contributor

bos commented May 24, 2012

(Imported comment by ross on 2007-11-01)

I don't recall a discussion where this was agreed, but I suspect that any partial solution (anything short of normalized names) will just move the problems around.

If foo-1.0 and FOO-2.0 and different versions of the same package, is one later than the other?

Contributor

bos commented May 24, 2012

(Imported comment by guest on 2007-11-02)

Hmm, I can't easily find it. It might have been on IRC or in person. It also might have been about names used by ghc-pkg rather than Cabal, but I don't think so. Or maybe I just dreamt it...

As I understood it, foo=FOO, so FOO-2.0 is later than foo-1.0 as 2.0 > 1.0.

Likewise, FOO-2.0 and foo-2.0 are the same version.

-- Ian Lynagh

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2007-11-02)

As I recall we agreed that hackage should enforce that there be no two packages with names that differ only by case. This was to allow distros to use lower case package names. I do not recall that we agreed to change the Eq instance for packages to make comparison case insensitive (this would have similar implications to redefining version equality in that == does not give the same result as comparing external representations).

Currently ghc & ghc-pkg treat package names case sensitively.

I don't mind changing it to be case insensitive everywhere, but if we do it we should do it everywhere.

Contributor

bos commented May 24, 2012

(Imported comment by guest on 2007-11-02)

(from BMeph)

One of the relevant issues I see, is that doing a cabal list will not only give any package of that name, upper or lower case, but any package with that character sequence in the package name - e.g., cabal list tv lists both TV and the GuiTV packages. This seems to me to be a reasonable behavio(u)r from the standpoint of searching for a package, of which its precise name one is unsure. Knowing that I can do a cabal list HXT after an unsuccessful "install" to find the proper package name, is a beneficial service to me.

Also, knowing that cabal list will give me that name, to be used in a cabal install reassures me that should two packages come along with near-identical names (HTTP, anyone?), that I can identify which one I want and get it with the cabal install. The greater particularity (?) of "cabal install"'s parameter should be documented, but I would rather it not be changed. However, when not finding a package , the error message it gives seems misleading/unhelpful to a worse degree than some of GHCi's ones. The error message should be changed, or somehow re-worked for a more informative response.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-01-14)

Implemented as per the original description. Applies to install, info and fetch commands.

@bos bos closed this May 24, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment