FromFile.jl's @from should be recognized by the julia-vscode extension

Tooling VS Code
, ,
1

FromFile.jl fans are pushing to integrate FromFile.jl functionality integrated into Julia itself. Part of the motivation is to improve compatability of the VSCode extension with FromFile.jl.

There was pull request to do so by MariusDrulea:

Recently, support for Revise.includet was added to the VSCode extension. I know this is slippery slope, but I think this should be strongly considered even if through a prototype unstable plugin mechanism.

This harkens back to @ChrisRackauckas’s question of when does a package become part of Julia?

Basically, at the moment we have a circular situation.

I am personally not a FromFile.jl user. I actually prefer to explictly order includes.

However, I do think it would be easier to add support for FromFile.jl in the vscode extension than it would be to incorporate this into the langauge. Given that this was recently done for Revise.jl, I think this should be reconsidered. Meanwhile, we should also consider Chris’s question in order to give better guidance to the vscode extension developers.

3 Likes
2

I think you have presented the situation well, thank you

also I give a big +1 to any and all tooling improvements in the vicinity of code loading, namespacing, etc.

1 Like
3

FromFile.jl is quite different though. It introduces implicit nonlocal behavior with undefined results in many trivial to construct cases. Generally, having one way to do things and having that way be explicit and well defined is preferable in programming. I think it’s fine for people to introduce personal shorthands which have undefined behavior on edge cases they purposefully avoid, but I don’t think it’s good to make such a behavior to be considered standard language semantics because then the undefined parts become only defined through implementation and is prone to breakage. We can see the unpythonic results this has had on Python (and the tie to CPython it creates) and so I think we should really consider a more robust design given we know the flaws.

9 Likes
4

I agree with you, Chris. There may some case for an intermediate solution such as a super-pkgimage consisting of multiple (sub)packages. However, I think our tooling may need to have a more expansive perspective of the language and that it would be better to transiently adapt the tooling rather the language itself.

Let’s not confuse my petition for FromFile.jl to be recognized by the julia-vscode extension with adopting FromFile.jl as the solution for #4600. It’s actually because I do not see any end resolution of #4600 in sight that I think the vscode extension should consider supporting FromFile.jl. In particular, I think this we relieve the language from pressure to adopt a solution.

Given that a pull request exists for this, I think we should consider it rather than rejecting on the basis of it not being a standard part of the language.

5

Just as a curiosity: can something like that be another extension in VSCode? Or something like a plugin? I guess I will be easier to maintain and upgrade VScode functionality targeting packages if they are more or less independent of the main VScode extension.

1 Like
6

Not really, no. We could come up with a plugin system for the linter (as mentioned here), but imo that’s not reasonable considering StaticLint.jl’s implementation.

2 Likes
7

Is there a mechanism to “develop” and hot patch the extension? How easy would it be for someone to maintain a light fork while we wait for a better plugin system to be developed?