better for cabal list to default to exact match or have an --exact option

[juhp]

I would like to suggest changing the behaviour of cabal list PKG to list only the info for the exact match PKG by default and not all packages containing the substring PKG, and adding a --all option to get back the current behaviour. Alternatively for better backward compatibility an --exact option could be added for this effect, leaving the current default behaviour of listing all matches.

Looking at https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/List.hs this seems possible though the code will need a little tweaking.

[ezyang]

I don't use cabal list so I'm OK with this. Don't know if anyone is relying on the specific result of this.

[v0d1ch]

I'd like to work on this one

[phadej]

Fixed in #6681 #6618

[hvr]

@v0d1ch Actually, I have an alternative design for this I've been wanting to implement for the longest time; listing exact matches is something I can already do via cabal info. What's the point of listing somethign where you already know the exact name for? :-)

The most common search operations I want to perform are simple prefx/suffix matching:

1. I want to only list packages which match a prefix (e.g. ^servant-)
2. I want to only list packages which match a suffix (e.g. -orphans$)

Now the primary bikeshedding thing is what syntax to support here; there's various possibilities; two obvious ones:

1. glob-style: this works best if we default to "exact" matches; this matches the shell idioms (c.f. ls foo and ls foo-*); substring matches would then be strings surrounded by *, i.e. *foo*.
2. regex-style: this makes sense if we default to substring search (as we currently do) which is how many regex-style supporting UIs operate as well (i.e. if you don't use any regex operators, it acts like substring search); note that you don't need any CLI flags here to switch to exact matches: you'd simply say ^foo$ to denote an exact match!

I'm not sure which one's better; and it's more than enough to start by implementing only a basic subset which allows the common pre/suffix matches.

But this is something we should decide upon before we add an unnecessary flag like --exact which then might end up becoming a hard to remove again UI-wart because we didn't invest enough time to plan ahead what other kinds of patterns would make sense to match and come up with a more holistic UI design (and cabal unfortunately suffers from many tiny features stuck together because they seemed useful in isolation but weren't considered how they fit to the rest...)

[phadej]

Open new issue, this feature is fixed.

[phadej]

I hate when old issues are re-opened with a scope creep. I will continue closing those kind of reopenings in the future too. New stuff is new stuff.

[hvr]

The problem was that this ticket's original scope was an XY issue and now was in fixed in a suboptimal way. That;s why I don't consider this a new request but rather a refinement of the root concern this ticket was covering. But I'm fine to open a new issue; it doesn't matter as long as the current incomplete "fix" doesn't make it into a release before this hasn't been properly addressed.

[phadej]

This issue was open for two years. It was simple enough for newcomer to pick up. And it wasn't refined before someone starts to work on it, I consider it's too late. Also Edward thumbed this up.

We have to improve on triage of the issues. I suggest that you look through newly opened PRs if you want to veto on them. This one was opened for 13 days, I consider that "not too quickly merged".

I do remember a lot of topics there are issues on, so I try my best to triage new issues. I didn't remember any discussions about cabal list, so I couldn't raise a flag on this one. It doesn't feel nice that issues are reopened, it makes one afraid to work on anything.

[juhp]

The use-case is cabal list --simple-output pkg, where I only want to see the versions of pkg.