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

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

Closed
DanBurton opened this issue Jun 1, 2015 · 9 comments
Closed

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

DanBurton opened this issue Jun 1, 2015 · 9 comments

Comments

@DanBurton
Copy link
Contributor

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.

@snoyberg snoyberg added this to the Later improvements milestone Jun 2, 2015
@Thooms
Copy link

Thooms commented Sep 27, 2015

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

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
#158 (comment)
.

@mrkkrp
Copy link
Collaborator

mrkkrp commented Nov 4, 2015

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

mgsloan commented Nov 5, 2015

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

mrkkrp commented Nov 5, 2015

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

mrkkrp added a commit to mrkkrp/stack that referenced this issue Nov 5, 2015
This commit introduces typo recommendations and minor refactorings in
‘Stack.Fetch’ module. Currently the recommendations follow very
conservative scheme only reporting package names for which
Damerau-Levenshtein distance between given package and package name in
caches is equal to 1. This should catch all common typos. If desirable,
the threshold can be made greater in future, although do it care because
it will quickly start to give false positives.
@mgsloan
Copy link
Contributor

mgsloan commented Nov 6, 2015

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 #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.

@mgsloan mgsloan closed this as completed in cb1bb44 Nov 6, 2015
@mgsloan mgsloan reopened this Nov 6, 2015
@mrkkrp
Copy link
Collaborator

mrkkrp commented Nov 6, 2015

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

mgsloan commented Nov 6, 2015

Yep, exactly!

mrkkrp added a commit to mrkkrp/stack that referenced this issue Nov 6, 2015
@mgsloan
Copy link
Contributor

mgsloan commented Nov 8, 2015

Good work!

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

No branches or pull requests

5 participants