For which packages does VSCode autocomplete work?

Tooling VS Code
,
21

My current workaround (when needing test-dependencies intellisense besides MyPackage.jl):

  • create a new MyPackageTest.jl project (at the same dir level as MyPackage.jl)
  • name the .jl files exactly as I would if I were writing the tests inside the test directory within MyPackage.jl
  • the entry point for MyPackageTest.jl only includes runtests.jl + force copy functionality (acting as a one-way mirror and replacing the test files inside MyPackage/test)

The only inconvenience is that I now need two VSCode instances - but no more issues with autocompletion (at least, this is the only way I can write tests with autocompletion for both the package I working on and the test dependencies).

I am thinking of making it a template that can be hydrated with any package.

I am not saying this in bad faith - but I feel that we shouldn’t need to try crazy workarounds to have decent tooling. But at the same time, I know that this is OSS - so my feelings are just that - feelings - I cannot really demand things.

Partially a joke: @gdalle, you’ll have to remove modern in front of the workflow when presenting the test side of things in your blog entry. :slight_smile:

2 Likes
22

Well, but we - as an OS community - can try to organize the development of high quality tooling if we need it. If 10000 Julia users pay 10 EUR each we could pay a full-time developer for a year…
OK, perhaps not so realistic, but with a mix of public, commercial and community funding it should be possible to pay someone to fix the vscode Julia issues…

I want to repeat my suggestion to have a Zoom call to do some brainstorming how this could be done…

3 Likes
23

I would pay.

2 Likes
24

A funny (and maybe inspiring) story from the F# community.

  • They created Fable - that transpiles F# to JavaScript (and these days to Rust, Python and more).
  • They used F# to develop the VS Code plugin for F# development (ionide) and compiled it to JavaScript.
  • The quality of the extension is just amazing.

/start :dream

The takeaway: let’s create JS.jl so lots of Julia developers can work on the tooling - and as a side effect, get Julia competitive in the web development area (not only as a backend language) and get an additional incentive for people to come to Julia.

Technically this should work.

/end :dream

8 Likes
25

:man_shrugging:

26

I am developing a package Foo. I am also developing a package Bar.

I’m writing a script and have include Foo and include Bar at the top of my script, but autocomplete does not work for either.

What should I do here to get autcomplete working again? Why is it broken?

1 Like
27

Do you mean using Foo and using Bar? In which environment are you working?

28

I’m using my default Pkg environment (called “1.9”), in which Foo and Bar are both devved.

You’re right I meant to say using

I’m finding it really hard to find any useful documentation or even code to help figure out the problem. I’m not averse to trying to solve this myself, but I really don’t know where to begin, so thank you for engaging!

29

Dev-ing the packages is a slight tweak of my initial question, perhaps this thread is more relevant:

31

What does “top of my file” mean: “top level” or “at the beginning of the file”?

32

no clue, somewhere in the file I guess

33

I believe the conditions are as follows.

  1. The package must be in the environment.
  2. VS Code must be configured to be using that environment.
  3. The file you are working with must either be
    A. A script that uses or imports the package in question.
    B. Included by the top level module named after the environment.
3 Likes
34

Suppose your directory looks like this:

D:\MyPkg.jl\
├── script\
│   └── main.jl
├── src\
│   ├── visualization\
│   │   └── utils.jl
│   ├── api.jl
│   └── MyPkg.jl
├── Manifest.toml
└── Project.toml

Then in script/main.jl I use the common LS trick:

false && include("../src/MyPkg.jl")

src/MyPkg.jl contains:

module MyPkg
include("api.jl")
include("visualization/utils.jl")
end

Observed behavior

Only the functions defined in api.jl get auto-completion / signature help / go-to-definition.
Functions from the subfolder file visualization/utils.jl do not get signature help or go-to-definition (sometimes only name completion appears).

Workaround I found

If I write in script/main.jl:

if false
    include("../src/MyPkg.jl")
    include("../src/visualization.jl")
end

then the functions from utils.jl start to auto-complete as well.

35

I’m developing a set of vision libraries and am running into this issue as well. This really makes Julia development unpleasant and more difficult than it should be. It seems I spent a lot of time trying to workaround these tooling issues rather than writing actual code.

Is this a VSCode issue or a LanguageServer.jl issue?

It seems to still be the case that LanguageServer.jl can only see symbols inside of a package. E.g., it cannot process dev’d packages or submodules, and it cannot find symbols in the test directory of a package. These are very big limitations on the developer.

2 Likes
36

I remember a really pleasant development experience with Juno/Atom, where symbols are resolved dynamically, essentially the same as you do edit(myfun). This also seems to be the only correct way to deal with a dynamic language, when the static code analysis-based approach in VSCode raises so many problems.

1 Like
37

Let’s see how GitHub - aviatesk/JETLS.jl: A new language server for Julia will solve this…

In the moment, this SW is a heavy work in progress, but it might be worth trying it out in a few months…

2 Likes
38

Thank you for the update.

There is increasing discussion about Julia’s growing adoption and the corresponding need for a central steering body to prioritize critical development efforts.

In my view, the current state of Julia’s tooling remains limited. Code introspection works only in narrow cases, often failing without clear explanation. A practical debugger is effectively absent—the interpreter is too slow for nontrivial workloads. Infiltrator is useful, but it is not a substitute for a fully capable debugger. As John Carmack has noted, complex systems often require developers to work largely within the debugger, and this gap becomes evident when compared to environments such as MATLAB, which offer both an excellent debugger and a strong REPL.

I recognize that addressing these issues is difficult, especially within an open-source ecosystem. I intend to contribute where I can, but solving the underlying static-analysis challenges needed for robust introspection is beyond my capabilities. Nonetheless, I believe this work is essential for the language’s long-term productivity and success.

But imagine you’re a new developer hacking on some interrelated packages. And you have no code introspection and then you come to the discourse and see that these problems have been discussed without resolution for 5 years. It could immediately turn someone off. Working on a large project without modern IDE tooling is a non-starter. It can be done, but at what cost: your competitors will just be faster than you and beat you to the punch, or you will blow past deadlines.

Actually I wonder how large Julia project maintainers deal with this? Maybe they can keep all of it in their head… But I’m surprised there isn’t more urgency to solve this problem.

5 Likes
39

So I switched over to eglot and tried this.

It is promising; it resolved several things right out of the box.

So I will eat a bit of crow from my last post. :slight_smile:

Thanks for the tip. I will continue to test it.

2 Likes
40

Some companies have 100kLOC Julia codebases I heard. I wonder how that works with the current tooling. For us it works roughly half the time but we are in the 10kLOC regime so we have most stuff still in our heads. But even if it works, in terms of features it is not as powerful as e.g. IntelliJ in terms of stuff like automatic refactoring etc.

IIRC the Atom/Juno approach was abandoned on purpose because it won‘t work if the package cannot be loaded. Of course if you also had static analysis that told you this ahead of time (whereas now you mostly need to try to load it anyway to discover missing imports etc. which could be known in advance), then it would allow a lot of introspection that is built into Julia already.

Loading/precompiling/testing a package is expensive, so tooling would ideally ensure that it isn‘t tried unnecessarily. We sometimes run halfway through a multi-minute test suite to get a LoadError that would have been obvious but was easy to overlook. Basically symbols that could have been found in the workspace and suggested, stuff like that.

1 Like