Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
juhp opened this issue Jan 26, 2017 · 13 comments
Closed

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

juhp opened this issue Jan 26, 2017 · 13 comments

Comments

@juhp
Copy link
Collaborator

juhp commented Jan 26, 2017

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
Copy link
Contributor

ezyang commented Jan 26, 2017

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
Copy link
Contributor

v0d1ch commented Mar 26, 2020

I'd like to work on this one

@phadej
Copy link
Collaborator

phadej commented Apr 9, 2020

Fixed in #6681 #6618

@phadej phadej closed this as completed Apr 9, 2020
@hvr
Copy link
Member

hvr commented Apr 9, 2020

@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...)

@hvr hvr reopened this Apr 9, 2020
@phadej
Copy link
Collaborator

phadej commented Apr 9, 2020

Open new issue, this feature is fixed.

@phadej phadej closed this as completed Apr 9, 2020
@phadej
Copy link
Collaborator

phadej commented Apr 9, 2020

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
Copy link
Member

hvr commented Apr 9, 2020

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
Copy link
Collaborator

phadej commented Apr 9, 2020

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
Copy link
Collaborator Author

juhp commented Apr 10, 2020

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

@phadej
Copy link
Collaborator

phadej commented Apr 10, 2020

So:

cabal list --simple-output --regex '^pkg$`

or

cabal list --simple-output --glob pkg

would work for you @juhp and make @hvr happy also?

@juhp
Copy link
Collaborator Author

juhp commented Apr 10, 2020

I think the prefix/suffix approach without a new option looks quite good.

@juhp
Copy link
Collaborator Author

juhp commented Apr 10, 2020

But I still find the current list behaviour surprising: naively I would not expect cabal list to do a package namespace search by default. But if we are constrained by back-compatibility maybe the only option would be to introduce new-list. ;-) If it was me, cabal list should probably be renamed to cabal search, and then cabal list would be just cabal list --simple-output --exact. That's my 2c anyway.

@phadej
Copy link
Collaborator

phadej commented Apr 10, 2020

I think it's modelled after ghc-pkg list [pkg], which doesn't do any search, matches have to be exact.

So I feel that consensus here is that changing the cabal-list to take regex(-like) inputs would be both backward-compatible, and solve @juhp original need?

@phadej phadej added this to the 3.4.0.0-rc1 milestone Jul 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants