-
Notifications
You must be signed in to change notification settings - Fork 18
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
[wip] Add binder #44
base: master
Are you sure you want to change the base?
[wip] Add binder #44
Conversation
Codecov Report
@@ Coverage Diff @@
## master #44 +/- ##
=======================================
Coverage 61.11% 61.11%
=======================================
Files 33 33
Lines 1638 1638
Branches 94 94
=======================================
Hits 1001 1001
Misses 632 632
Partials 5 5 Continue to review full report at Codecov.
|
Took some doing, but things seem to work up to viewing (locally). Will post a Binder screenshot... probably broke a bunch of stuff, and may need to make some separate PRs (that might be good to land before 3.0 final, perhaps). |
@fcollonval Haven't gotten around to warming this up, but the approach has legs, and it's worth checking out the binder. As this PR has gotten rather large (like i do), I think an effective path forward might be to do some refactoring before trying to land this: Some of those could go on 3.x...
but some of the bigger ones might need to be 4.x...
|
Awesome work @bollwyvl - sorry to not look into this earlier.
Agreed, I'll help open small PRs.
vscode GitHub plugin uses the GitHub search API. And the user can customize groups like this: "githubIssues.queries": [
{
"label": "My Issues",
"query": "default"
},
{
"label": "All Bugs",
"query": "state:open repo:${owner}/${repository} sort:updated-desc label:type:Bug"
},
{
"label": "All Features",
"query": "state:open repo:${owner}/${repository} sort:updated-desc label:type:Enhancement"
}
] We could add a config button in the frontend panel that would open a form allowing the user to customize the search in a similar way. The question being do we want it to be a setting or a state?
What do you think of aiocache?
Yep this definitely needs redesign of the extension code. |
@@ -203,7 +207,7 @@ async def _call_provider( | |||
break | |||
|
|||
new_ = json.loads(result) | |||
if next_url is not None: | |||
if has_pagination and next_url is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
has_pagination
should not be added - but if you have a better API idea it would be great.
As the next_url
contains already all required parameters, has_pagination
is passed as False
when calling the next page (see line 217). But if there are more than 2 pages, requiring has_pagination
to be True
will block calling the page 3, 4,... .
Unfortunately bringing the pagination in the frontend will be tricky to pull all the discussions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, unfortuntately i don' think we can just always assume it's okay to pull down 1000 PRs indiscriminantly...
@@ -252,7 +250,7 @@ async def list_prs(self, username: str, pr_filter: str) -> List[Dict[str, str]]: | |||
) | |||
|
|||
# Reset cache | |||
self._merge_requests_cache = {} | |||
self._merge_requests_cache = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you reset the cache to None
and not an empty dictionary? The idea to set as an empty dictionary is to allow to use the get method line 455.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be a screwup...
@@ -204,7 +201,7 @@ async def list_prs(self, username: str, pr_filter: str) -> List[Dict[str, str]]: | |||
) | |||
|
|||
# Reset cache | |||
self._pull_requests_cache = {} | |||
self._pull_requests_cache = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you reset the cache to None
and not an empty dictionary? The idea to set as an empty dictionary is to allow to use the get method line 298.
I'm pretty sure a it should be settings on the frontend, as it would need an "interesting" UI to make it useful, but only the provider knows what the fields are. Basically, we'll want each search provider to create a JSON schema for "what is a search" that can be mapped to whatever the search provider has, and the provider would have to provide what it knows. So anonymous would only know about:
A full github/gitlab/bitbucket/gitea provider knows about the above, and (probably) a ton of other things, plus it could go off and do other queries to provide autocomplete values. Anyhow, so the client would PUT a body that conforms to that, and then have a search that existed for the duration of the server lifetime. When the server restarts, you'd chunk back into it. |
environment.yml
: normal stuff, alsojupyterlab-tour
andnbgitpuller
postBuild
: pretty much what CI doesjupyter notebook
.binder/jupyter_config.example.json
PRConfig
object instead of unpacking it