You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm curious if you think it would be reasonable to add some options to a session for choosing the Juliaup channel and project. For an entire org file I can use a local variable, so if I want to use the 1.8 channel and a project in the same directory as the org file, it looks like this:
# Local Variables:
# julia-vterm-repl-program: "julia +1.8 --project=."
# End:
This applies to every source block in the file, so I can't use this method to run code in one session on the lts channel and in another session on the release channel, for example. You can pretty easily have different projects in different sessions by, e.g., using Pkg; Pkg.activate("."), but as far as I know there isn't a way to specify command line arguments for the julia executable per session to get different Juliaup channels.
This isn't actually impeding my current workflow, but here's the use-case I was thinking of: I'm planning to do some writing with one org file containing multiple blog posts. I might want to make the Julia in each post a bit more reproducible via specific choices of Juliaup channels. The obvious solution is "well just don't do it that way", so no worries if you think this isn't a useful addition.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi @benide.
Thanks for the interesting idea. It would be useful to select juliaup channel, not only for your specific use-case. I think it can be achieved by extending the julia-vterm-repl-buffer function in julia-vterm.el. I will see if there is any potential implications. It is a bit low priority for now, but I am thinking I am going to implement it. Thanks!
If some means to specify the Julia command line via a header argument (by analogy :kernel in emacs-jupyter) then it could be specified on a per source block basis (not my actual workflow but interesting) and it would allow per project configuration also. (I use an org setup file for each project). This is the only feature that keeps me using emacs-jupyter. Be very cool to enable this if all it needs is an org header variable to override the default, just like :session. Just call it :julia and specify the command line. I think that would be very flexible.
Hi @sebeaumont
Thank you for trying out ob-julia-vterm.el and I appreciate your comment.
Currently, the only available option to specify a Julia program to be used is to use a buffer-local variable julia-vterm-repl-program. This is a functionality provided by julia-vterm.el. I completely agree that allowing the specification of the Julia command line in a Org header argument would be a valuable addition. This flexibility would enable per-project/session configuration and make workflows more adaptable. I am very interested in implementing this feature.
I've been enjoying ob-julia-vterm!
I'm curious if you think it would be reasonable to add some options to a session for choosing the Juliaup channel and project. For an entire org file I can use a local variable, so if I want to use the 1.8 channel and a project in the same directory as the org file, it looks like this:
This applies to every source block in the file, so I can't use this method to run code in one session on the
lts
channel and in another session on therelease
channel, for example. You can pretty easily have different projects in different sessions by, e.g.,using Pkg; Pkg.activate(".")
, but as far as I know there isn't a way to specify command line arguments for the julia executable per session to get different Juliaup channels.This isn't actually impeding my current workflow, but here's the use-case I was thinking of: I'm planning to do some writing with one org file containing multiple blog posts. I might want to make the Julia in each post a bit more reproducible via specific choices of Juliaup channels. The obvious solution is "well just don't do it that way", so no worries if you think this isn't a useful addition.
Thanks!
The text was updated successfully, but these errors were encountered: