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
base: main
Are you sure you want to change the base?
Conversation
I will add validation (the squiggles) in a separate PR. |
a40d835
to
f80411b
Compare
f80411b
to
6d10e23
Compare
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. |
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? |
I have this intention, though prototyping the feature in the frontend (TypeScript) was faster because I mostly avoided recompiling the language server |
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.
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 |
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.
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") |
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.
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 |
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.
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) |
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.
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).
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.
@davidanthoff, please take a look at julia-vscode/LanguageServer.jl#1055.
*/ | ||
async function _executeUpdateCommand(level: UpgradeLevel) { | ||
const projectRoot = vscode.workspace.workspaceFolders[0] | ||
const updateCommand = `julia --project=. -e "using Pkg; Pkg.update(;level=Pkg.${level})"` |
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.
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.
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.
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] |
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.
I would expect the update command to update the currently active project, not just what is in the root, right?
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. |
So be it, I will move it to the LS. |
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. |
No |
Just dummy codelenses at the moment.
- The only job of the class was to provide encapsulation a namespace can do the job. - Fix some typing holes in `dep`.
- 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.
96ea934
to
7b06823
Compare
fcae5c2
to
bea72cd
Compare
0e2e51e
to
c879329
Compare
Add
hovers
, andcodelens
forProject.toml
files. It provides a compilation of the features in Version Lens, theGolang
extension, and the nativepackge.json
support in VSCode. A demo 👇demo.mp4
Some problems I am not sure how to approach
How to get theResolved in 04fa3df.stdlib
modules names? Currently, a package is assumed to be an@stdlib
if it's not found in any registry.Pkg.status
prints directly tostdout
, the format is parsable though I am not sure whether it's consistent across versions or not.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?For every PR, please check the following: