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

Packages hovers and lenses #2373

Open
wants to merge 52 commits into
base: main
Choose a base branch
from

Conversation

AbdulrhmnGhanem
Copy link
Contributor

@AbdulrhmnGhanem AbdulrhmnGhanem commented Aug 15, 2021

Add hovers, and codelens for Project.toml files. It provides a compilation of the features in Version Lens, the Golang extension, and the native packge.json support in VSCode. A demo 👇

demo.mp4

Some problems I am not sure how to approach

  • How to get the stdlib modules names? Currently, a package is assumed to be an @stdlib if it's not found in any registry. Resolved in 04fa3df.
  • How to get the status of the current packages? Pkg.status prints directly to stdout, the format is parsable though I am not sure whether it's consistent across versions or not.
  • Running julia --project=. -e "using Pkg; Pkg.update()" pipes the output in the `stderr whether the operation succeeded or failed, how to determine if it was an actual failure?
  • ArgTools.jl needs to get added to the VSCodeServer.

For every PR, please check the following:

  • End-user documentation check.
  • Changelog mention.

@AbdulrhmnGhanem
Copy link
Contributor Author

I will add validation (the squiggles) in a separate PR.

AbdulrhmnGhanem added a commit to AbdulrhmnGhanem/julia-vscode that referenced this pull request Aug 16, 2021
AbdulrhmnGhanem added a commit to AbdulrhmnGhanem/julia-vscode that referenced this pull request Aug 16, 2021
AbdulrhmnGhanem added a commit to AbdulrhmnGhanem/julia-vscode that referenced this pull request Aug 16, 2021
@davidanthoff davidanthoff added this to the Next Minor milestone Aug 23, 2021
@pfitzseb
Copy link
Member

  • How to get the status of the current packages? Pkg.status prints directly to stdout, the format is parsable though I am not sure whether it's consistent across versions or not.
  • Running julia --project=. -e "using Pkg; Pkg.update()" pipes the output in the `stderr whether the operation succeeded or failed, how to determine if it was an actual failure?

So the way I'd handle this is by spawning a new (re-useable) terminal or Outputs channel (and focusing it). That way we don't need to determine the success of the commands ourselves and instead leave that to the user.

@davidanthoff
Copy link
Member

This is a fantastic feature!

One pretty fundamental comment: should this not just be part of the language server? That consideration should probably not stop us from merging here, i.e. I could also imagine that we merge this approach here first and then later migrate it into the LS, but in general that seems to be the better place?

@AbdulrhmnGhanem
Copy link
Contributor Author

should this not just be part of the language server?

I have this intention, though prototyping the feature in the frontend (TypeScript) was faster because I mostly avoided recompiling the language server

Copy link
Member

@davidanthoff davidanthoff left a comment

Choose a reason for hiding this comment

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

Ok, I took a closer look now :)

I think my main concern is that using the REPL process for querying the registry is not how we want to do this, for many reasons. It might be blocked because it is running code, we shouldn't start a REPL to show these IntelliSense things etc. I think the proper solution here would be to have this functionality in the LS, but if that is too involved for now then I think it would even be better to just spawn a new Julia process that simply queries the registry and then immediately returns.

I guess the main question really is how difficult it would be to move this into the LS?

.gitmodules Outdated
@@ -58,3 +58,6 @@
[submodule "scripts/packages/IJuliaCore"]
path = scripts/packages/IJuliaCore
url = https://github.com/JuliaLang/IJuliaCore.jl.git
[submodule "scripts/packages/Tar"]
path = scripts/packages/Tar
url = https://github.com/JuliaIO/Tar.jl.git
Copy link
Member

Choose a reason for hiding this comment

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

The changes in this file don't seem to match the submodules that are added in this PR? Not sure how that can happen...

@@ -0,0 +1,38 @@
include("../../RegistryQuery/RegistryQuery.jl")
Copy link
Member

Choose a reason for hiding this comment

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

We generally have all the code that loads packages in src/VSCodeServer.jl, so maybe move it there?

@@ -0,0 +1,471 @@
# The content of a registry is assumed to be constant during the
Copy link
Member

Choose a reason for hiding this comment

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

Maybe put this file into a src folder, just to be more consistent?

return LensResponse(RegistryQuery.UnknownPkgMetadata)
end

const lens_request_type = JSONRPC.RequestType("lens/pkgVersions", LensParams, LensResponse)
Copy link
Member

Choose a reason for hiding this comment

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

So it seems to me that all of this code should definitely not live in the REPL process. The REPL might not be running when someone opens a Project.toml, but that shouldn't be a reason that this functionality doesn't work, right?

I think if incorporating this into the LS is too involved right now, then it should still live in its own process (which, though, doesn't seem less work than just moving this functionality into the LS).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

*/
async function _executeUpdateCommand(level: UpgradeLevel) {
const projectRoot = vscode.workspace.workspaceFolders[0]
const updateCommand = `julia --project=. -e "using Pkg; Pkg.update(;level=Pkg.${level})"`
Copy link
Member

Choose a reason for hiding this comment

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

This needs to pickup the configured Julia version, not just generic julia. You can take a look at say the task runner to see how to get that value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I couldn't find an example of what you meant.

* Execute `Pkg.update` and display its output while executing in an output channel.
*/
async function _executeUpdateCommand(level: UpgradeLevel) {
const projectRoot = vscode.workspace.workspaceFolders[0]
Copy link
Member

Choose a reason for hiding this comment

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

I would expect the update command to update the currently active project, not just what is in the root, right?

@davidanthoff davidanthoff modified the milestones: Next Minor, Backlog Sep 4, 2021
@davidanthoff
Copy link
Member

Also moving this to the backlog for now, as I don't think we can get this ready for the next minor version merge window.

@AbdulrhmnGhanem
Copy link
Contributor Author

So be it, I will move it to the LS.

@davidanthoff
Copy link
Member

Fantastic, and sorry for the extra hoops here. Are you on the slack channel vscode-dev? I think especially at the start we'll have to figure out how exactly we integrate it into the LS, and I'd be more than happy to iterate on that on slack and help with getting you up-to-speed on the LS design. We could also schedule a zoom call if you want.

@AbdulrhmnGhanem
Copy link
Contributor Author

AbdulrhmnGhanem commented Sep 4, 2021

Are you on the slack channel vscode-dev?

No

- Metadata (the latest version of the package, repo url, registry to
  which it belongs) will be displayed on hovering over a `deps` field.
- To make the users control whether they want to load packages
  information or not; query the registries lazily when the users click
  on the contributed menu icon.
- The hover provides had to be split into multiple ones; hovering over
  the fields in the [deps] section will always return, then the other
  hover are unreachable.
- The [deps] fields will always return if the registries aren't
  initialized, i.e., the user hasn't clicked the versions icon.
- The hover now are (aware) of the status of the registry query, the
  reigstry query can be one of (hasn't been queried yet|loading|return
  the package info).
- compat fields don't have uuids so the should get deduced from the
  package name.
- Remove the version field.
- Display the standard library link.
- Supprot major, minor, patch, and fixed updates
- Previously, if a package isn't found in any registry, it was
  considered an stdlib module.
- Now, we check if it's an actual stdlib module.
- Also, flag unknown packages if any.
- The output channel can display the result of `update` operation while
  it's running; using event listener on the `stderr`.
- The event listener is on `stderr` because the update `Pkg.udapte` pipe
  the result into `stderr` whether it's successful or not.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants