make an ijulia "app" entrypoint - #1211
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1211 +/- ##
==========================================
+ Coverage 70.21% 71.08% +0.86%
==========================================
Files 17 17
Lines 1276 1314 +38
==========================================
+ Hits 896 934 +38
Misses 380 380 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
JamesWrigley
left a comment
JamesWrigley
left a comment
There was a problem hiding this comment.
Looks like this will need to be gated behind a @static if VERSION >= v"1.11" to support 1.10.
| Starting with Julia 1.12, you can launch IJulia directly from the command line using the `ijulia` command. First, you need to install the app entry point by running in the Julia REPL: | ||
|
|
||
| ```julia | ||
| pkg> app add IJulia |
There was a problem hiding this comment.
I think IJulia is one of the few packages that still has a build step 😅 Shall we just install the app automatically when building? My only concern is that from reading the docs it seems that an app is somehow hardcoded to a specific Julia binary? That's a bit unfortunate because we recently added a juliaup integration that reduced the need for rebuilding IJulia to once per minor release (#1201). And perhaps if it's that experimental we should leave it out by default, can always enable it later.
There was a problem hiding this comment.
I think IJulia is one of the few packages that still has a build step 😅
I thought about this and I even have a started branch that removes the build step.
Moves the kernel installation into the package and auto-installs on first kernel launch and uses a scratch space to keep the preference (https://github.com/JuliaPackaging/Scratch.jl).
What do you think about that? Build scripts are not that great...
But anyway, once I've fixed a bug, app installation should run the build step like normally.
There was a problem hiding this comment.
That sounds ok, as long as it still installs the same kernels as now. @stevengj, what do you think?
|
Update from comments. Since (from making this PR) I noticed that build support is kind of broken (will require a small fix) it is probably best to wait to merge this until a julia 1.12 has come out with that fix (or that the build step has been migrated away from). |
e7d1c1c to
5487958
Compare
|
The windows test failure can be ignored, there's something still wrong with the kernel shutdown logic that causes it to hang on windows.
How is build support broken? 👀 |
this makes ijulia installable via the Pkg app interface: https://pkgdocs.julialang.org/v1/apps/ and allows one to do e.g. ``` pkg> app add IJulia ``` and then run e.g. ``` ijulia lab ``` in the terminal to start an ijulia jupyterlab notebook without having to launch julia itself and load IJulia explicitly.
|
|
JuliaLang/Pkg.jl#4491 should fix the app build issue. But really, this whole build thing is kind of user hostile 😆. Like, there is code in here to just do what the user want but instead they get an error and have to do some Anyway, I'll work on my no-build branch. |
|
Off-topic rant, but: Honestly, I think |
|
You're in luck 😉 #1215 |
3 participants
this makes ijulia installable via the Pkg app interface: https://pkgdocs.julialang.org/v1/apps/ and allows one to do e.g.
and then run e.g.
in the terminal to start an ijulia jupyterlab notebook without having to launch julia itself and load IJulia explicitly.
To test this PR you can do
Pkg.Apps.develop(path=abspath("."))(the relative path is currently bugged), make sure.julia/binis in the PATH and then runijulia.