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

Take environment variables directly from the _environment file #217

Closed
albertomercurio opened this issue Nov 26, 2024 · 6 comments
Closed
Labels
bug Something isn't working

Comments

@albertomercurio
Copy link

Following this page on the official documentation of Quarto, it is possible to define environment variables directly inside the _environment file. This is very useful when we need to define many variables used on many files.

Apparently, the only way that works so far is by writing the following yaml in each file

engine: julia
julia:
    env: ["JULIA_NUM_THREADS=16", "JULIA_CONDAPKG_BACKEND=Null", "JULIA_PYTHONCALL_EXE=../pyenv/bin/python"]
@MichaelHatherly MichaelHatherly added the bug Something isn't working label Nov 27, 2024
@MichaelHatherly
Copy link
Collaborator

With the following file structure I was able to retrieve envvars that were set in an _environment file:

/
  _environment
  _quarto.yml
  file.qmd

_environment:

FOO=bar

file.qmd:

---
engine: julia
---

```{julia}
ENV["FOO"]
```

_quarto.yml:

which did give the correct output:

image

@albertomercurio with the above MWE are you also able to see the same output, or does that also fail for you?


What does not work for me, is changing the value of an envvar set in that file while the julia process that runs the server is active, since it appears to me that those environment variables are defined when that process starts up. When they are later changed and a new render is requested they can't be reset. Quarto does not pass them as data to the server process from what I can tell, otherwise we could intercept them and define them correctly.

Perhaps this is the same behaviour as other engines.

@albertomercurio
Copy link
Author

Oh, yes. I was using export VARIABLE=something, but it should be without export.

I think we can close this issue. But, I have just one related question. I have now the following environment variables needed for PythonCall.jl

JULIA_NUM_THREADS=16
JULIA_CONDAPKG_BACKEND=Null
JULIA_PYTHONCALL_EXE=pyenv/bin/python

but the python path is relative to the _environment file location. This means that if I have a .qmd file in a subfolder, this will fail. Is there a way to define the python variable without explicitly write the absolute path of the python executable?

@MichaelHatherly
Copy link
Collaborator

I have now the following environment variables needed for PythonCall.jl

Does setting those just in the first cell of your notebook that needs then, via ENV["JULIA_PYTHONCALL_EXE"] = ..., work for you? Picking the value of the path dynamically based on the location of the notebook.

@albertomercurio
Copy link
Author

I'm currently using the following yaml configuration on each .qmd file

julia:
    env: ["JULIA_NUM_THREADS=16", "JULIA_CONDAPKG_BACKEND=Null", "JULIA_PYTHONCALL_EXE=../pyenv/bin/python"]

since they are simply in the next subfolder. I was searching for something global.

I tried to write something dynamics in the _environment file, like

JULIA_PYTHONCALL_EXE=$(which python)

to automatically take the python path. but this doesn't work.

@MichaelHatherly
Copy link
Collaborator

MichaelHatherly commented Nov 29, 2024

In a ```{julia} cell though? Not in the julia.env frontmatter key:

```{julia}
ENV["JULIA_PYTHONCALL_EXE"] = ...
```

```{julia}
using PythonCall
```

I'd assume something like that would be fine, PythonCall is only loaded after the env var is set. It's not like setting threading for julia via an env var where it has to happen prior to start up.

@albertomercurio
Copy link
Author

Ok thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants