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

Allow using a heuristic with the doesitcache tool #118

Open
ionrock opened this issue Mar 30, 2016 · 4 comments
Open

Allow using a heuristic with the doesitcache tool #118

ionrock opened this issue Mar 30, 2016 · 4 comments

Comments

@ionrock
Copy link
Contributor

ionrock commented Mar 30, 2016

Often times CacheControl be confusing b/c something seems like it should be cached, but it is not. There is typically a good explanation for this and work around that comes in the form of heuristics. It would be helpful for the doesitcache tool to accept a heuristic.

Specificially:

  1. doesitcache --list-heuristics - list the available heuristics and print the docstring of the classes
  2. doesitcache --heuristic $NAME - Apply an heuristic. There might be options that need to be passed in, which seems to go above and beyond at the moment. Just making sure heuristics have defaults should be enough
  3. doesitcache --heuristic $PATH - Use the file to load a python object as the heuristic. The algorithm would be to import it and see what classes are instances of the heuristic base class, choosing the first one to apply.

Docs!

Thanks to @sigmavirus24 for the suggestion!

@sigmavirus24
Copy link
Contributor

You might want to change to load heuristics through entry-points to make life simpler (that way someone doesn't shove a bunch of heuristics in one module and get upset when they can't use the path). Alternatively, you might want to something like:

doesitcache --list-heuristics   # to list the default heuristics
doesitcache --heuristic cachecontrol.heuristics.ExpiresAfter <url>
doesitcache --load-heuristics-from path/to/module.py --heuristic HeuristicDefinedInModule <url>

but realistically I think the last one should also take the fully qualified name to avoid naming collisions when using the tool and that would just be path.to.module.HeuristicDefiendInModule but that case you might want to be special in the even that path is not importable.

@ionrock
Copy link
Contributor Author

ionrock commented Mar 30, 2016

@sigmavirus24 That is a good idea. The entrypoint bit is a pain in the neck, but --list-heuristics might be helpful there.

@sigmavirus24
Copy link
Contributor

Yeah, the entry-points are probably a bit of overkill but also make some of these features easier. I'm torn on it personally.

@elnuno
Copy link
Contributor

elnuno commented Apr 11, 2017

Any updates on this? Is it up for grabbing or should I leave it be? :)

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

No branches or pull requests

3 participants