I recently started using Julia and I am really digging it. I am currently just trying to get comfortable with a practice project (writing a toy convolutional network using Flux.jl and using HTTP.jl to get the training data and building a data-processing pipeline using core Julia, though it isn’t too important).
I am used to developing mostly in C++ and Python in environments that have pretty competent auto-complete and tooling. In whatever language I work in I typically start out by discovering the community standard work-flow. I have been trying to figure out what that work-flow is in Julia.
I have pretty much settled on Juno. I typically prefer VS Code to Atom, but Juno seems pretty standard compared to the current VS Code Julia extension. However, I have been bumping up against some oddities that I am hoping that you can help me understand.
I have noticed that I only get auto-completions for modules that are currently imported/used in the REPL. Notably, if the REPL isn’t currently active, I only get auto-complete for basic language constructs and Latex symbols. Is this normal, is there no offline auto-complete provider like Jedi for Python? I view this as a pretty huge issue. It is a pretty bad user experience to have to load up the REPL, activate the environment, and import any packages/currently worked on functions. In addition, I can get auto-completes for modules/functions that are not loaded for that file just because they are active in the REPL. This is generally “feels bad” in terms of user experience. Moreover, this form of auto-complete is a large potential security risk (one of the reason Python does not do auto-complete this way).
Is there a good blog/article covering Julia 1.0+ best practices? A lot of what I read is for 0.5, 0.6, etc. and it is hard to know what is and is not good to listen to.
Revise.jl and OhMyREPL.jl look pretty interesting. Obviously I don’t want to pollute my main environment for my project, and I don’t want to stick them in the base Julia environment (v1.1 for me). I know I can stick them in another environment and add that to my LOAD_PATH environment variable and set the setup in my “startup.jl”. Beyond that though, is there a standard setup?
That is all for now. The auto-complete/file-editing tooling is really the biggest thing. I appreciate any help.
While OhMyREPL is mostly a neat package that makes the REPL look nicer, Revise is one of the key packages out there and I would say it’s to the point that it’s part of what you’d call a “standard” workflow (and I think many out there would have it in their startup.jl)
I’m not aware of an autocomplete beyond the one that you experienced (which I personally quite like but maybe I just got used to it). One side note though is that afaik you don’t need to “activate the environment” all the time.
Just use VS-Code…
I don’t use it, but I understand that after Atom, VS-code is the second most popular editor.
(especially if we ignore vim and emacs).
And it does have the kind of autocomplete you expect.
Others have at various times reported success getting the julia language server (as used by VSCode) working in a variety of editors, including vim and atom.
I personally use TabNine, via deomplete in neovim these days.
Why not put them in the base Julia enviroment?
That is what most people do.
Personally, Revise, OhMyRepl, Debugger and BrenchmarkTools are the only packages I have in my base julia enviroment
That’s interesting. So what do you do when working on a package that is made to work with other packages? Or when you want to visualize things? Do you have environments specifically for that?
Juno indeed doesn’t have something like that right now, but VSCode does.
The fundamental problem with an actual offline autocomplete is that it’s impossible – you need to load packages to know what they define (at least if you want to catch everything). LanguageServer.jl (which is what powers the VSCode plugin) uses SymbolServer.jl to cache that information, which it gets from loading all packages in separate processes once.
It certainly is very different and requires you to adopt a more dynamic workflow, yes. If you don’t like it then you’ll need to use a different editor for now, sorry – and as Lyndon says, VSCode should do what you want.
Can you elaborate on that?
I have some long term plans to improve the “static workflow” in Juno (by basing it on LanguageServer.jl), but I doubt I’ll find the time and motivation for that super soon
I create a new enviroment, and I dev --local each package I am working that work together in it.
Or if one is the main package that I am working on, and I just need to improve a dependency,
then I will activate that main package as an environment and dev --local the dependency.
Sometimes I do both, because I am a maverick.
Or when you want to visualize things? Do you have environments specifically for that?
Yes, since installing packages that have already been installed somewhere else is basically instantaneous, and I value being able to just take a whole project folder and give it to someone and have them able to repeat e.g. my visualizations, then i do indeed do that.
Sometimes I do install things into the my global enviroment, either because I am lazy or by mistake. But I always keep to the believe that it should be ok for me to wipe the global enviroment at any time.
That is to say I do not depend on having anything there for my other environments to work.
