Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with directories #228

Closed
mtiller-jh opened this issue Nov 7, 2023 · 6 comments · Fixed by #229
Closed

Issue with directories #228

mtiller-jh opened this issue Nov 7, 2023 · 6 comments · Fixed by #229

Comments

@mtiller-jh
Copy link

mtiller-jh commented Nov 7, 2023

I've created the following repo that demonstrates an issue I'm seeing. I'm getting errors of the form:

SystemError: opening file "./other/sample-4.svg": No such file or directory

...and I cannot understand why. The README in the repo explains exactly how to reproduce the issue but the bottom line is that when running scripts from different directories, the behavior of Literate.jl seems to change although it isn't obvious to me why.

Am I doing something obviously wrong? The scripts are nearly identical, the only difference that I can really see is whether the file being executed is in the current directory or not.

@jvaverka
Copy link
Contributor

jvaverka commented Nov 7, 2023

Not sure as to the root cause, but this issue can be avoided by using the joinpath method instead of relative path strings. These files updates both run successfully.

# run-from-root.jl
using Literate

Literate.markdown(
    joinpath(@__DIR__, "docs", "sample.jl"),
    joinpath(@__DIR__, "other");
    execute=true,
    flavor=Literate.CommonMarkFlavor()
)
# docs/run-from-docs.jl
using Literate

Literate.markdown(
    joinpath(@__DIR__, "sample.jl"),
    joinpath(@__DIR__, "..", "other");
    execute=true,
    flavor=Literate.CommonMarkFlavor()
)

fredrikekre added a commit that referenced this issue Nov 7, 2023
This patch fixes a bug where `Literate.markdown` with `execute=true`
would (try to) output images in the wrong directory. This only occured
when passing a relative output directory. Fixes #228.
fredrikekre added a commit that referenced this issue Nov 7, 2023
This patch fixes a bug where `Literate.markdown` with `execute=true`
would (try to) output images in the wrong directory. This only occured
when passing a relative output directory. Fixes #228.
@fredrikekre
Copy link
Owner

fredrikekre commented Nov 7, 2023

Thanks for the report, this is fixed in release 2.15.1 (JuliaRegistries/General#94947 for the registry PR) by 7fc9958

When executing code Literate cd to the output directory. When writing the image file the un-processed raw output directory was still used. The fact that working case worked was that Literate cd do other, then write the image to ../other, which is undoes the cd and it ended up in the correct directory...

I tend to always be explicit about paths and use absolute paths though, but it should of course work otherwise as well.

@mtiller-jh
Copy link
Author

The issue I see here is that by cding to the output directory, any paths referenced in the input files are invalid. For example, if I do:

using Pkg
Pkg.activate(".")

...in my input file, it tries to look for a Project.toml in my output file which is quite counter intuitive. It seems like, when evaluating a Julia script, we should set the current directory to where that Julia script is, no?

@fredrikekre
Copy link
Owner

I am sure there are arguments for both options, I just copied the behavior from Documenter. The current behavior is nice if you save files, for example, since they end up where the code is executed.

@mtiller-jh
Copy link
Author

I see. Yes, that makes sense. The flip side is, of course, what happens if the script needs to read input files. I'm trying to keep my input files and output files in completely different directories. One option could be for the Runlit approach to inject a variable that provides context on where the input files are located. I'll explore that. Thanks.

@mtiller-jh
Copy link
Author

OK, I resolved it for myself at least.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants