-
|
Hello, I have seen many similar discussions but have not really found a solution for my situation. I am on Linux (Pop!_OS) and quarto is installed on the system. When I try to render a .qmd file, I get a However, I must note that I have installed jupyter in the system (in the past) as well as in this conda env. However, I think quarto is using the system kernel because the one of the conda env is not even listed in For the record, in VS Code, with the conda environment activated there, I can interactively run all the cells with no problem and the seaborn module is correctly loaded. However, clicking on the
Thanks is advance! |
Beta Was this translation helpful? Give feedback.
Answered by
m-pauper
Apr 18, 2023
Replies: 1 comment 6 replies
-
|
Without a "not working" reproducible example, it's going to be hard or likely impossible to help. Could you also double check that you followed documentation on using Conda with Quarto? See https://quarto.org/docs/projects/virtual-environments.html#using-conda. |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
Hi, thanks for the answer. In the meantime, I just made a new test conda environment with I also made a clone of the actual environment which gives me the problem and recreated the environment in another location, it keeps giving a problem with Here's the specification of the env: |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I am not a huge Conda user (or a huge fan for that matter, i.e., I prefer Python venv). If this is a Conda issue what you seem to say now, I would suggest to go on a more specialised website for help on Conda, such as StackOverflow for example. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the tips! I have realized what I think is the source of the problem. The whole project directory (and as such, the directory where the conda env was created) is mounted on my local computer with sshfs. It seems that even though When I clone this conda environment to another local location (not sshfs-mounted) and activate that one instead for rendering, then things work as expected. I imagine this behavior is expected in this scenario. Since this is a discussion, I'd appreciate your take on what is the cleanest way to deal with situation like this, where the entire project actually resides on a remote machine. I chose to mount the directory and have the computations done locally because of other limitations on the remote machine (e.g. unable to have a VS Code remote to that machine because of old glibc version) . |
Beta Was this translation helpful? Give feedback.
Answer selected by
m-pauper
-
|
I do not know enough on how Quarto file system handler is working to give actionable insights. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Mickaël! I would argue that sshfs is not exactly "syncing", rather the directory is directly mounted on your system. Even so, I agree that it's less than ideal, but is sometimes the only option when it is impossible to work directly on the remote machine. In any case, thanks for the insight. I will mark this solved and hopefully it can be useful for someone else in the future. |
Beta Was this translation helpful? Give feedback.
-
|
I will paste @cderv answer because it might help.
|
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks for the tips!
I have realized what I think is the source of the problem. The whole project directory (and as such, the directory where the conda env was created) is mounted on my local computer with sshfs. It seems that even though
quarto checkseems to correctly detect the python and jupyter in that conda env, when it comes to rendering it reverts to using my system-wide python and jupyter (where seaborn is not available).When I clone this conda environment to another local location (not sshfs-mounted) and activate that one instead for rendering, then things work as expected.
I imagine this behavior is expected in this scenario.
Since this is a discussion, I'd appreciate your tak…