# VSCode LOAD\_PATH discussion
**URL:** https://discourse.julialang.org/t/vscode-load-path-discussion/34085
**Category:** VS Code
**Tags:** code-organization
**Created:** [January 30, 2020, 6:20pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085 "2020-01-30T18:20:26Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [January 30, 2020, 6:20pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/1 "2020-01-30T18:20:26Z")
> [@Improve debugger GUI to help adoption?](https://discourse.julialang.org/t/improve-debugger-gui-to-help-adoption/33708/26):
>
> I would be much more happy if you would fix three year old issues like this one: [https://github.com/julia-vscode/julia-vscode/issues/307](https://github.com/julia-vscode/julia-vscode/issues/307)
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.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [January 30, 2020, 6:23pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/2 "2020-01-30T18:23:32Z")
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.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [January 30, 2020, 6:31pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/3 "2020-01-30T18:31:51Z")
> [@ufechner7](#):
>
> Well, the load\_path issue affects a lot of users that do professional Julia development. The debugger probably more beginners.
I don’t share that assessment (neither part) 🙂
> [@ufechner7](#):
>
> 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.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [January 30, 2020, 6:33pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/4 "2020-01-30T18:33:21Z")
> [@ufechner7](#):
>
> Well, the load\_path issue affects a lot of users that do professional Julia development. The debugger probably more beginners.
I’m pretty stunned by this statement. Well, the last part.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [January 30, 2020, 6:57pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/5 "2020-01-30T18:57:26Z")
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. ☹
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [January 30, 2020, 7:05pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/6 "2020-01-30T19:05:04Z")
Can we move this discussion to the relevant github issue? This thread here is really about the debugger 🙂
---
### Author:  [@ianfiske](https://discourse.julialang.org/u/ianfiske)
#### Post date: [January 30, 2020, 7:06pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/7 "2020-01-30T19:06:03Z")
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.
EDIT: we can move this to the GH issue too 🙂
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [January 30, 2020, 7:08pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/8 "2020-01-30T19:08:57Z")
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.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [January 30, 2020, 7:10pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/9 "2020-01-30T19:10:04Z")
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?
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [January 30, 2020, 8:04pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/10 "2020-01-30T20:04:35Z")
> [@ufechner7](#):
>
> Doesn’t make sense, because the relevant developers don’t listen to the comments in that issue.
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!
---
### Author:  [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)
#### Post date: [January 30, 2020, 8:18pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/11 "2020-01-30T20:18:27Z")
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.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 31, 2020, 9:56am UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/12 "2020-01-31T09:56:01Z")
> [@ufechner7](#):
>
> I work for customers, I cannot decide to create packages
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.
---
### Author:  [@ihnorton](https://discourse.julialang.org/u/ihnorton)
#### Post date: [February 2, 2020, 3:51pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/13 "2020-02-02T15:51:16Z")
> [@davidanthoff](#):
>
> EDIT: Could one of the mods split the whole discussion about `LOAD_PATH` in VS Code into a separate thread? Thanks!
✔
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [February 3, 2020, 7:09pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/14 "2020-02-03T19:09:37Z")
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.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [February 3, 2020, 8:42pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/15 "2020-02-03T20:42:02Z")
Messing with `LOAD_PATH` pretty much became obsolete with the new package manager. I can understand if it isn’t considered a priority for tool makers.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [February 3, 2020, 8:42pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/16 "2020-02-03T20:42:45Z")
> [@ufechner7](#):
>
> But why should have create a package if I don’t need one?
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).
---
### Author:  [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)
#### Post date: [February 3, 2020, 8:53pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/17 "2020-02-03T20:53:37Z")
> [@ufechner7](#):
>
> But why should have create a package if I don’t need one?
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.
Speaking frankly, your tone in the many discourse topics where you’ve complained about this issue as well as in [Linter doesn't check `LOAD_PATH` for packages · Issue #307 · julia-vscode/julia-vscode · GitHub](https://github.com/julia-vscode/julia-vscode/issues/307) is abhorrently entitled and disrespectful to the _volunteer_ maintainers of vs-code Julia.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [February 3, 2020, 9:12pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/18 "2020-02-03T21:12:18Z")
> [@non-Jedi](#):
>
> abhorrently entitled
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.
Jedi
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [February 3, 2020, 9:20pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/19 "2020-02-03T21:20:34Z")
> [@non-Jedi](#):
>
> packages/environments are the canonical way of organizing code in Julia
First of all, I am using environments.
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.
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [February 3, 2020, 10:00pm UTC](https://discourse.julialang.org/t/vscode-load-path-discussion/34085/20 "2020-02-03T22:00:20Z")
> [@ufechner7](#):
>
> 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:
```julia
...
├── julia
│ ├── Manifest.toml
│ ├── Project.toml
│ ├── src
│ │ └── MyPackage.jl
│ └── test
│ └── runtests.jl
├── README.md
...
```
When I `activate` the `julia` directory I can do `using MyPackage`. `dev`ing other local directories with that structure also works fine.
If you want to register the package, the situation is more complicated. See [https://github.com/JuliaLang/Pkg.jl/issues/1251](https://github.com/JuliaLang/Pkg.jl/issues/1251) for a discussion.
[Next page](https://discourse.julialang.org/t/vscode-load-path-discussion/34085.md?page=2)