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

Separate python/intepreter api and extension api #10494

Merged
merged 5 commits into from
Jun 18, 2022
Merged

Conversation

rebornix
Copy link
Member

Re #10152

There are two types of APIs

  • Python/Intepreter APIs which we build on top of Python extension
  • API we expose to other extensions, defined in extension.d.ts

This PR attempts to separate these two. The first group API sits in platform and can be used by other components, while the extension api is moved out of platform and should not be used by any internal/primitive component.

  • Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
  • Title summarizes what is changing.
  • Has a news entry file (remember to thank yourself!).
  • Appropriate comments and documentation strings in the code.
  • Has sufficient logging.
  • Has telemetry for feature-requests.
  • Unit tests & system/integration tests are added/updated.
  • Test plan is updated as appropriate.
  • package-lock.json has been regenerated by running npm install (if dependencies have changed).

@rebornix rebornix self-assigned this Jun 17, 2022
@rebornix rebornix marked this pull request as ready for review June 17, 2022 20:46
@rebornix rebornix requested a review from a team as a code owner June 17, 2022 20:46
Copy link
Contributor

@rchiodo rchiodo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering what platform is anymore? You're moving 'global' things to webviews/extension-side, but isn't it the same as being platform? What does platform represent if not global things?

@codecov-commenter
Copy link

codecov-commenter commented Jun 17, 2022

Codecov Report

Merging #10494 (ec8d9eb) into main (c925935) will decrease coverage by 0%.
The diff coverage is 100%.

@@          Coverage Diff           @@
##            main   #10494   +/-   ##
======================================
- Coverage     71%      71%   -1%     
======================================
  Files        467      467           
  Lines      28072    28073    +1     
  Branches    4736     4736           
======================================
- Hits       19959    19935   -24     
- Misses      6230     6251   +21     
- Partials    1883     1887    +4     
Impacted Files Coverage Δ
src/kernels/types.ts 100% <ø> (ø)
src/notebooks/languages/cellLanguageService.ts 69% <ø> (ø)
src/platform/api/pythonApi.ts 69% <ø> (ø)
src/platform/api/serviceRegistry.node.ts 100% <ø> (ø)
src/platform/api/types.ts 100% <ø> (ø)
src/platform/common/utils.ts 80% <ø> (ø)
src/telemetry/types.ts 100% <ø> (ø)
src/extension.node.ts 76% <100%> (ø)
src/webviews/extension-side/api/api.ts 45% <100%> (ø)
...rc/webviews/extension-side/api/apiAccessService.ts 45% <100%> (ø)
... and 14 more

@rebornix
Copy link
Member Author

rebornix commented Jun 17, 2022

I'm wondering what platform is anymore? You're moving 'global' things to webviews/extension-side, but isn't it the same as being platform? What does platform represent if not global things?

Discussed with @rchiodo offline about the wording and definitions, especially around what "global" means in the context.

There are two types of "global" components. The first group includes utilities(logging), helper functions (vscode-path), or infra code (ioc). The second group includes global standalone classes/components (e.g., extension api, data viewer), they are not used by other components (i.e., notebooks, kernels), but are exposed to extension.node/web.ts.

During my refactoring, I tried to use src/platform for components in the first group, and use src/webviews/extension-side for the second group. Neither of the folder names are intuitive so we can discuss how we are going to call them. One idea I have now is:

  • src/base, for infra and utilities code.
  • src/platform, for global standalone classes.

src/base is the component everyone can depend on, and src/platform is the top component, which can use anything but can't be depended on.

@microsoft/datascience-vsc-team-reviewers thoughts?

@rebornix rebornix merged commit b821681 into main Jun 18, 2022
@rebornix rebornix deleted the rebornix/extension-api branch June 18, 2022 01:24
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

Successfully merging this pull request may close these issues.

3 participants