* Automatically install latest pyspark version
* Better text
* Do not use shutil to keep behaviour
* Make setup_script cwd independent
* Use _get_program_version to calculate spark version
* Update setup_spark.py reqs
* Update setup_spark.py
* Add info about HADOOP_VERSION
* Add customization back
* Better text
* Specify build args when they are actually needed
* Better text
* Better code
* Better code
* Better text
* Get rid of warning
* Improve code
* Remove information about checksum
* Better text
* Fix Docker healthcheck when using custom runtime dirs
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Use a writable directory for healthcheck test
* Allow missing import for `jupyter_core` in mypy
* Set HOME according to NB_USER in healthcheck script
* Add custom runtime dir an NB_USER case to healthcheck test
* Call `jupyter --runtime-dir` directly in healthcheck script
* Update docker_healthcheck.py
* Update docker_healthcheck.py
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Ayaz Salikhov <mathbunnyru@users.noreply.github.com>
* 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>
* Link to the rocker/binder image as an alternative
* Unify style in README.md
---------
Co-authored-by: Ayaz Salikhov <mathbunnyru@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
* Fix conda hook to work in both terminal and Jupyter Notebook
* Fix hook for Jupyter Terminals
* Rename startup hook to have order of precedence
* Try to increase sleep
* Comment making env_name default in custom_environment
* 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
