* Fix `max(stable_versions)`
Since the keys are semantic version strings, that means that `"1.9.4" > "1.10.0", which we know isn't true. 🙂
I just added some code to convert the string to tuples, find the max, then convert back to a string.
I first noticed this on the `2024-01-05` build of the `datascience-notebook`, since Julia 1.10.0 was released ~2 weeks ago: https://github.com/JuliaLang/julia/releases/tag/v1.10.0.
* Migrate to comparator on `max(stable_versions)`
* Update setup_julia.py
* Update setup_julia.py
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: Ayaz Salikhov <mathbunnyru@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Modify the custom Python kernel
- to activate the custom environment
- for the respective Jupyter Notebook and Jupyter Console
Signed-off-by: Ayaz Salikhov <mathbunnyru@gmail.com>
* Add DL3059 to hadolint ignore list
Signed-off-by: Ayaz Salikhov <mathbunnyru@gmail.com>
* Move hadolint ignore to a single line
* Use python heredoc
* Remove unused print
* Fix style
* Do not hardcode CONDA_DIR
* Update custom_environment.dockerfile
* Use indent=1
* Implement activate_notebook_custom_env.py as a separate script
* Do not call Python manually
---------
Signed-off-by: Ayaz Salikhov <mathbunnyru@gmail.com>
Co-authored-by: Olivier Benz <olivier.benz@b-data.ch>
* Automatically install latest julia version
* Better text
* Fix
* Fix
* Update setup-julia.bash
* Install plumbum
* Better docs
* Better docs
* Use subprocess.check_call instead of plumbum
* Do not use dash in python filename
* Remove plumbum from the image
* Remove jq from the image
* Remove setup-julia.bash file
* Fix file name
* Fix docstring
* Specify multiple architectures for Julia to precompile to
For amd64 (x86_64), we should specify what specific targets the
precompilation should be done for. If we don't specify it,
it's *only* done for the target of the host doing the compilation.
When the container runs on a host that's still x86_64, but
a *different* generation of CPU than what the build host was, the
precompilation is useless and Julia takes a long long time to start
up. This specific multitarget comes from
https://docs.julialang.org/en/v1/devdocs/sysimg/#Specifying-multiple-system-image-targets,
and is the same set of options that the official Julia x86_64 build is
compiled with. If the architecture the container runs on is
different, precompilation may still have to be re-done on first
startup - but this *should* catch most of the issues.
h/t to
https://discourse.julialang.org/t/is-it-possible-to-make-precompilation-portable-for-docker-images-built-with-a-different-cpu/95913
which helped point me towards `JULIA_CPU_TARGET`.
Fixes https://github.com/jupyter/docker-stacks/issues/2015 for more information
* Fix bash syntax issue
* Add JULIA_CPU_TARGET for aarch64 as well
- Don't need `export` as this is only used within this
script
- Steal from upstream what should be setup for aarch64
* Re-add export for JULIA_CPU_TARGET
Quietens pre-commit
