pyjulia to invoke Julia from Python. PySR thus have a dependency on SymbolicRegression.jl.
The current procedure involves first installing PySR via
conda and then installing SymbolicRegression.jl by invoking this command
python -c 'import pysr; pysr.install()'. That command invokes the julia package manager.
What I believe may soon be possible is using the julia package manager during conda-forge packaging so that the user does not need a second installation step. They could just
import pysr and start using it.
The mechanism that conda or an operating system package manager could use to supply Julia packages is by populating a depot on Julia’s depot stack. From the docs for
Base.DEPOT_PATH, we see there are three depots by default.
- ~/.julia where ~ is the user home as appropriate on the system;
- an architecture-specific shared system directory, e.g. /usr/local/share/julia;
- an architecture-independent shared system directory, e.g. /usr/share/julia.
Within a conda environment this becomes
By manipulating the environment
JULIA_DEPOT_PATH, we can add a depot. Because conda-forge does not currently package individual Julia packages, one way to “install” Julia packages via conda would be to ship a Julia depot located in
That depot just needs four directories.
- artifacts - binary artifacts that the packages may need
- conda - this just contains a deps.jl configuring Conda.jl
- environments - preconfigured Julia environments that can loaded via
- packages - Julia source code
The easiest way to create this depot is to first set
JULIA_DEPOT_PATH to a temporary directory. Alternatively, within Julia one could do:
DEPOT_PATH_BACKUP = copy(DEPOT_PATH)
From there add the needed packages and create the environments desired. Before exiting Julia, copy the desired folders such as “packages” to the depot location (e.g.
Now we just need to set
JULIA_DEPOT_PATH. For example, one could do the following.
Within julia one could also do
push!(DEPOT_PATH, joinpath(ENV["CONDA_PREFIX"], "share/pysr/depot")