VSCode LOAD_PATH discussion

You need one, you just don’t realize it.

This is a misconception. Julia packages are very lightweight (comparable to branches in git). They are part of the normal workflow.

You can of course have multiple modules in a git repository. For all Julia cares, you can have your whole ~ in a git repository. This is an orthogonal question.

That said, the current tooling makes it slightly more convenient to have a repo for each package. But nothing prevents you from cloning a repo, pkg> devig a “main” project, which has relative paths to other modules in the manifest.

The bottom line is that there is a solution to your workflow problem, so refusing to use it and sticking to the obsolete LOAD_PATH puts you in a position where it may be difficult to get community support.

1 Like

While I appreciate all the suggestions made in this thread, to say that LOAD_PATH is obsolete is a bold statement.
Where can I find this information in the Julia documentation?
Where can I find the information: If you want to structure your code using modules, please create a Package first?
I do not think that this statement is backed by facts, correct me if I am wrong.

I don’t see why you would trust documentation more than the people that tend to write the documentation / package manager directly telling you something. If the docs suggest that modifying LOAD_PATH is a good workflow for everyday use, then they should be amended.

Maybe this is the core of the problem. This is not true. A julia package needs:

  • A file called Project.toml with a UUID and name entry.
  • A file src/Package.jl file that defines module Package ... end.

generate in Pkg creates this for you if you do generate Package.

Anyway, It is totally fine to use scripts (not packages) but then you tend to just include by path which doesn’t require modifying LOAD_PATH.

5 Likes

For the sake of argument, I will assume vscode extension is competing with Juno to win over users, and you have to choose between developing debugger or support for LOAD_PATH

I was comparing Juno and vscode a year ago, and used both of them at the same time for comparison. And eventually decided to use vscode even LOAD_PATH doesn’t work on vscode at that time. Because I could work around LOAD_PATH problem with pkg>dev MyModule

So, I think a lack of support for LOAD_PATH would be fine. if enough users are going to adopt pkg>dev MyModule as their workflow.
But on the other hand, If users want to use Debugger have no choice but use Juno.

So if the final goal of vscode is to win users over Juno, I think debugger is a more pressing matter because Juno has them and there is no workaround to use debugger in vscode.

You can compare current and pre-Pkg3 docs. TL;DR: LOAD_PATH used to be part of the recommended workflow, and for most purposes these uses have been superseded by the new Pkg workflow. LOAD_PATH is still there but it is no longer something users would modify routinely.

In the discussion above, for example, with multiple people telling you this. A lot of the documentation is catching up about these things, and there are WIP issues, but the idea of using projects to organize your code has been around since the first JULEP on the issue.

I think you are approaching this wrong. We are not talking about how to interpret a fully specified standard, but solving a problem in the context of the current code loading and Pkg features, some of which are WIP.

I think that applies here (1/b). Perhaps pkg> activate would be a better choice.

I guess I see the problem.

Meanwhile:

  1. Julia 1.0
  2. new Pkg
  3. reinvented workflow

So, while one can still consider it a vscode bug it is just not meant to be the common workflow. Thus, rather than complaining about missing support for pre-1.0 style (whose support is allowed to be dropped in 1.0 according to SemVer) you might need to go with the time and update your own workflow for the post Julia 1.0 world. Requesting stronger support in that direction is like requesting Tier 1 support for pre 1.0 Julia.

As kristoffer said, LOAD_PATH in the workflow & package sections can be considered outdated and thus an issue/PR would be a good idea.

But as that all won’t help you (and tbh I still am wrapping my own head around the new best practices/workflow) there are some resources & discussions which might help you wrapping yours around:

  1. Workflow Tips · The Julia Language
  2. Julia workflow
    and a few more which I can’t find right now. One of this community also wrote a blogpost last year IIRC.

Either way, Julia is (fortunately) still fast evolving, though, since 1.0 (sadly) only in a very restricted non-breaking manner. (Looking forward to 2.x).

Is that even needed? I was able to dev folderFoo, where the only thing in folderFoo is src/folderFoo.jl, but no Project.toml.

3 Likes

Okay, that’s a remnant for backwards compat with REQUIRE files. Gone on 1.4 though.

1 Like

Ah, good to know.

So I tried to dev my project. This is how far I got:

cd ~/myproject
julia --project

(myproject) pkg> dev .
ERROR: expected a `name` entry in project file at /home/ufechner/myproject/Project.toml

(Myproject) pkg> dev .
ERROR: expected a `uuid` entry in project file at /home/ufechner/myproject/Project.toml

(Myproject) pkg> dev .
ERROR: expected the file `src/Myproject.jl` to exist for package Myproject at .

(Myproject) pkg> dev .
ERROR: Cannot `develop` package with the same name or uuid as the project

(Myproject) pkg> 

And the Project.toml file:

name = "Myproject"
uuid = "e522e412-47e6-11ea-24f1-c3520112404c"

[deps]
AbstractTrees = "1520ce14-60c1-5f80-bbc7-55ef81b5835c"
...

I fixed the first three errors, but I do not know how to fix the last one.

Any idea?

If it is a project, I would just pkg> activate it. Which you are already doing the way you invoke Julia.

Why would you want to dev a project within itself? I don’t think that makes sense. I think that reading the first few chapters of the Pkg docs would be useful at this point.

TL;DR:

  1. one would usually work with a project by activating it (which is what you are doing above).

  2. if it is a package that you are developing, you may want to dev it in the default project.

1 Like

The point is, I was told that I shall NOT use LOAD_PATH and that vscode finds functions that are defined in modules of a dev’ed package.

But this does not seam to work.

@ufechner7, I think you just need to read up on how to use env and how the dev thing works. What you are attempting in your example (to activate the local folder as the active project, and then dev the local folder) is not how the env support in Julia works.

1 Like

In other words, there is no viable alternative to the use of LOAD_PATH.

You just have to be in your standard environment, then you can dev your project and type “using MyProject”. Any changes to your project will be automatically available via Revise. Then the linter should also work. You only use the environment of your project when you want to change which packages are loaded by your project. That’s it, I tried that as well (I didn’t check the linter part, but can do so at the next opportunity).

1 Like

I tried now turning on the Linter and I still get the “Missing Reference” annotation for the dev’d package even after “using MyPackage”. So it does not seem to be a solution to the problem after all.

I can confirm than using “dev .” does not help to make the linter work.

But another work-around was found and is described in the following comment: Linter doesn't check `LOAD_PATH` for packages · Issue #307 · julia-vscode/julia-vscode · GitHub :slight_smile:

Thanks to this new workaround I was able to get rid of 1200 false positives (warnings). 5-6 warnings remained, indicating real problems. :slight_smile:

2 Likes

Glad that some temporary solution was found :slight_smile: I’ll try it later