FS#63255 - [julia] @which and @edit do not work

Attached to Project: Community Packages
Opened by Benoît Legat (blegat) - Monday, 22 July 2019, 15:46 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 22 March 2020, 10:00 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
For stdlib files, the `@which` and `edit` functions do not look at the files in the right directory. The prefix `/build/julia/src/julia-1.1.1` should be removed.

Additional info:
* package version: julia 2:1.1.1-3

Steps to reproduce:
```julia
@which ones(1, 1) * ones(1, 1)
*(A::AbstractArray{T,2} where T, B::AbstractArray{T,2} where T) in LinearAlgebra at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/LinearAlgebra/src/matmul.jl:141

julia> @edit ones(1, 1) * ones(1, 1)
# Tries to open /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/LinearAlgebra/src/matmul.jl:141
```
The path should be `/usr/share/julia/stdlib/v1.1/LinearAlgebra/src/matmul.jl`
This task depends upon

Closed by  Antonio Rojas (arojas)
Sunday, 22 March 2020, 10:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  julia 1.4.0
Comment by Eli Schwartz (eschwartz) - Tuesday, 23 July 2019, 01:21 GMT
  • Field changed: Summary (@which and @edit do not work → [julia] @which and @edit do not work)
  • Field changed: Category (Packages → Upstream Bugs)
As far as I can tell, our julia package is doing everything it is supposed to be doing. If julia is caching the file paths from the build environment when naming the location of a source definition, this isn't fundamentally wrong -- and I guess @which is still returning correct information which is understandable. The fact that @edit apparently tries to open the same file could be argued to be the fault of the language for offering such an odd feature, or else the fault of -- still -- upstream for hardcoding bad things in the build system

BTW: if you download the prebuilt binaries from https://julialang.org/downloads/ and try running that, it tries to edit the file /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/LinearAlgebra/src/matmul.jl:141 instead.

So it seems quite obvious to me this isn't intended to work for things in the language's standard library -- and really, why would you want to, since you probably won't have write access to it anyway?

My advice: submit an upstream bug report asking for the build system to respect and strip the prefix= defined in Make.user, or better yet, embed a symbol denoting that it is part of the stdlib and causing the @edit feature to refuse to operate on such files.
Comment by Jingbei Li (Petron) - Sunday, 04 August 2019, 07:46 GMT
Hi, I'm the maintainer of `julia-mkl` on AUR and it also suffers from this bug.

> My advice: submit an upstream bug report asking for the build system to respect and strip the prefix= defined in Make.user, or better yet, embed a symbol denoting that it is part of the stdlib and causing the @edit feature to refuse to operate on such files.

Is there an upstream bug report now?
I can help to follow it and do some tests.
Comment by Eli Schwartz (eschwartz) - Monday, 05 August 2019, 05:20 GMT
I've gone ahead and searched their github for you. I found an old, open issue for it: https://github.com/JuliaLang/julia/issues/26314

I also found someone who just days ago submitted https://github.com/JuliaLang/julia/pull/32763 in relation to it. Try checking to see if this fixes your problem.
Comment by Jingbei Li (Petron) - Friday, 16 August 2019, 04:04 GMT
PR #32763 does fix @less and @edit. But it doesn't affect @which.

I'll keep an eye on it.
Comment by Alexander F. Rødseth (xyproto) - Monday, 02 September 2019, 15:11 GMT
While waiting for upstream, I guess it's possible to create a symlink from /build/julia/src/julia-1.1.1/usr/share/julia/ to the correct location on the system. Or perhaps we can patch it. But I would prefer if upstream could make this easier and/or fix it.
Comment by Eli Schwartz (eschwartz) - Monday, 02 September 2019, 16:40 GMT
It's possible, but it would also violate the packaging guidelines... packages are not allowed to install anything to $HOME, wtf.

(Among numerous other issues, the package will fail to install once built, because it will clash with the source files.)
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 03 September 2019, 05:42 GMT
To be clear, I never meant installing anything to $HOME, that would be silly.
Comment by Eli Schwartz (eschwartz) - Tuesday, 03 September 2019, 12:21 GMT
But /build is the $HOME directory of the build chroot, that is exactly the whole point!

It doesn't matter whether you call it "$HOME" or "$srcdir", it is still) wrong...
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 04 September 2019, 09:20 GMT
I was brainstorming around possible solutions. I said "I guess it's possible", together with two other solutions, not "this is a good solution and the one I am choosing". Better ideas are warmly welcome.

Loading...