Nice-to-have: typo recommendations for UnknownPackageIdentifiers

DanBurton commented 9 years ago

UnknownPackageIdentifiers (fromList ["stackage-metdata-0.3.0.0"])

It would be nice if it could notice that I was only off by one character from stackage-metadata.

Thooms commented 9 years ago

Hi! I'd be interested in working on that feature if it hasn't been taken care of yet :) Do I have to expose some kind of design here first, or just submitting code + tests is enough?

snoyberg commented 9 years ago

Submitting code should be sufficient. If you have any questions, let us know!

On Sun, Sep 27, 2015, 6:59 PM Thomas Papillon notifications@github.com wrote:

Hi! I'd be interested in working on that feature if it hasn't been taken care of yet :) Do I have to expose some kind of design here first, or just submitting code + tests is enough?

— Reply to this email directly or view it on GitHub https://github.com/commercialhaskell/stack/issues/158#issuecomment-143571031 .

mrkkrp commented 9 years ago

Is there any progress on this? In case this is not being worked on, a couple of questions here:

How do I reproduce it on command line level? stack fetch is not available (sorry if the question is basic).
Should it just print something like “did you mean ‘stackage-metadata’?” or anything fancier is desirable? How exactly do you expect it to react?
My idea is to put the new message in fuzzyCandidatesText when fuzzy is Nothing (fuzzyLookupCandidates just selects packages with the same name and the same major version, right?), so when it fails to find anything we should assume a typo before giving up, and if it's not a typo, then fuzzyCandidatesText will be empty. Tell me if I'm wrong.
Do you want to catch only these simple typos or something decent is desirable? Damerau-Levenshtein distance is a good way to catch typos from my experience (and here is a package: edit-distance that can be used). If we decide to go with this approach and just a message is enough, then we could extract package names calculate Damerau-Levenshtein distance between actual input and every unique package name, filter only sufficiently close names (distance 1 is a good threshold in this case, IMO) and present them to user.
Can I refactor existing code while I'm at it? (Not sure I will do it, but I want to know.)

mgsloan commented 9 years ago

How do I reproduce it on command line level? stack fetch is not available (sorry if the question is basic).

mgsloan@computer:~$ stack build stackage-metdata-0.3.0.0
Run from outside a project, using implicit global project config
Using resolver: lts-3.10 from implicit global project's config file: /home/mgsloan/.stack/global/stack.yaml
Didn't see stackage-metdata-0.3.0.0 in your package indices. Updating and trying again.
Fetched package index.                                                                                    
Populated index cache.    
The following package identifiers were not found in your indices: stackage-metdata-0.3.0.0

Should it just print something like “did you mean ‘stackage-metadata’?” or anything fancier is desirable? How exactly do you expect it to react?

How about

The following package identifiers were not found in your indices: stackage-metdata-0.3.0.0
Perhaps you meant "stackage-metadata"?

When there are multiple close results, like for stackage-updoate:

Perhaps you meant "stackage-upload" or "stackage-update"?

Do you want to catch only these simple typos or something decent is desirable?

I think Levenshtein distance is a good choice. Also, a larger threshold than 1 is better, and then just have a limit on the number of results.

Can I refactor existing code while I'm at it? (Not sure I will do it, but I want to know.)

Certainly! I prefer to keep large refactorings in separate commits, but small ones can go along with the changes.

mrkkrp commented 9 years ago

One more question. Why do you have constraints like:

resolvePackagesAllowMissing
   :: (MonadIO m, MonadReader env m, HasHttpManager env, HasConfig env, MonadLogger m, MonadThrow m, MonadBaseControl IO m, MonadCatch m)
    => …

Is it just desire to keep the code as general as possible or do you need to use resolvePackagesAllowMissing and the like in different monads that are instances of all these classes? Is it possible to have one monad that is instance of all these classes and specify it in type signatures (and therefore do most things inside of this monad)? Sure, the code will be less general, but is this generality actually useful? (Sorry, I'm still quite unfamiliar with your code-base, so probably I'm just missing something.)

mgsloan commented 9 years ago

There are indeed circumstances where some functions are used with different reader environments. However, I think it is true that many are always called with the same monad. I've opened https://github.com/commercialhaskell/stack/issues/1297

I've merged the commit, but I'm going to leave this open for now to track this :

[ ] Give the suggestions at the end of the output, after the The following package identifiers were not found in your indices:. Otherwise it's easier to miss them.

mrkkrp commented 9 years ago

@mgsloan, To give the suggestions at the end of output, they should be included in exception and then printed as part of exception. Am I correct?

mgsloan commented 9 years ago

Yep, exactly!

mgsloan commented 9 years ago

Good work!

commercialhaskell / stack

Nice-to-have: typo recommendations for UnknownPackageIdentifiers #158