That is a tricky issue that interacts with a lot of other stuff. In particular, we are still not done fixing our general environment handling story, and we need to coordinate a fix for the LOAD_PATH issue with the other changes we are making there. Sometimes that means we need to put things on hold until we have shipped the current set of fixes and get some real world experiences whether that works or not.
Also, there is always a trade-off situation, and the question where do we get the biggest return for our efforts. While this LOAD_PATH issue is annoying, it is at the same time a corner issue that probably doesn’t affect too many users. I’m sure the debugger, on the other hand, would be used by a much larger number of folks. So that in my calculation bumps it up in terms of priority.
Well, the load_path issue affects a lot of users that do professional Julia development. The debugger probably more beginners. So you might be right, there are probably more beginners than professionals.
The other issue is that the communication between the linter and the core part of the vs-code plugin is still not documented, which makes it very hard for other people to step in.
Yeah, that is a problem. But this issue in particular is so complicated and entrenched in the depths of the whole extension, and an area where Zac and I are still fiddling with some very core design questions, that I honestly don’t think anyone other than Zac or I can fix this. Even if there was documentation, someone would have to invest a very, very significant amount of time to be able to fix this particular issue.
I think you think too complicated. I am not looking for a perfect, elegant solution, but just for something that works, even if it uses a hack.
I cannot seriously suggest Julia for any professional work as long as this issue is not fixed: A reliable linter is crucial, something like “goto definition” for functions. Juno does not have it. And to be able to split a module into two or three if it becomes too large is also crucial if you want to write maintainable code. And this is not possible with vscode as long as the load_path issue is not fixed. The main piece of code I am working at is now more like 2000 lines of code, I really would like to split this into two modules, but then I would loose the “goto definition” functionality of vscode, so I am not doing it. Bad code quality due to bad tools. Frustrating. Nothing I can suggest to use for professional software development.
Just curious @ufechner7 – why do you need to manipulate LOAD_PATH manually in order to break your code into multiple modules? Are you avoiding creating/using packages? Pkg environments provide the tools for managing a project with multiple packages, wherever those packages live.
I work for customers, I cannot decide to create packages, and packages also don’t make much sense if you just want to brake up one large program into modules.
Doesn’t make sense, because the relevant developers don’t listen to the comments in that issue.
Alternatively, moving this discussion to another thread in discourse could make sense.
As background information, the reason why I am so frustrated is that this all used to work three years ago, but since 2.5 years it doesn’t work any more, and there seams to be no way forward to fix it.
So the questions remains, how can we get an IDE that is good enough for professional software development without relying on people from academia, who might have other priorities?
I track that issue, I’ve responded often on that issue and I’m actively thinking how we might be able to fix this, it is just not a simple fix and that is why it takes time.
EDIT: Could one of the mods split the whole discussion about LOAD_PATH in VS Code into a separate thread? Thanks!
You can decide to work within a single package as you’re doing your development even if your customers don’t use the code that way. Then within that package, you can have all the modules you like, and the language server will work perfectly fine. You don’t have to break it down to 1 module = 1 package.
I am not sure I understand this. Presumably you deliver you code somehow, and packages are just an organized way to do this — if you include a manifest, your customers also get a reproducible environment.
But why should have create a package if I don’t need one? A lot of unnecessary overhead.
I prefer to have one git repository for one program, which might include 5 modules to split up the code in units that can be tested separately.
If I have a new co-worker or student I just have to give him or her access to one repository. Easy. And one Readme.md. And he or her can start hacking.
One can easily dev local folders into an environment that are not full blown packages in their own git repo. I think the minimal requirement that something can be deved is just that there is a folder src, and then a file ModuleName.jl in that src folder. No need for anything else, as far as I can tell (certainly not a git repo).
If you can’t be bothered to create a single file (Project.toml can be easily generated by Pkg.instantiate()) and put a single file named EnvironmentName.jl into a src subdirectory, I don’t see why tooling should go out of its way to support your workflow–it can already easily exist within a package. Like it or not, packages/environments are the canonical way of organizing code in Julia, and messing around with LOAD_PATH will probably continue to cause pain.
Well, I do not know what to say. Julia needs a good IDE, and the current development process, that is based on very few people is not optimal.
I would like to contribute, but I cannot because of the complicated design and the lack of documentation.
That’s all I can say for now.
Perhaps we see us in Lisbon and can discuss this issue in person.
Packages are useful for many purposes, but not for every purpose. In particular not for organizing the code of a single program.
Lets give a different example: I have some code (a flight controller) written in C++, and a model, written in Julia, and want to test the C++ controller against the Julia model.
Then I make a Julia folder in the C++ repository and use that code for testing. But this is just a small add-on to the C++ code. So using a separate repository for the model is just too much overhead. And as far as I know every Julia package needs a separate git repository.
For local use, definitely not. You just need to have the usual directory structure and a src/MyPackage.jl file which defines a MyPackage module. When I have a julia component inside a larger repository with other stuff, I usually have the file structure:
