Julia pre installed in Linux distro like python

[giordano]

@novemberist

but is maintaining a seperate fork of LLVM with patches applied specifically for building Julia really the way to move forward? Sounds to me (naively spoken) like it would make more sense to get those patches merged upstream somehow than to fragment the llvm ecosystem with such customizations?

It isn’t a completely different product, there are relatively few changes. For example, for LLVM 18 the total diff is 10 commits, 5 of which are actually commits already in llvm upstream (but not in the v18 series, so they were backported) which were found to be necessary for proper functioning of the Julia compiler. The remaining commits haven’t been deemed to be useful for generic llvm (although with some effort could perhaps be polished and upstreamed) and four out of five of them touch five lines or less each, and we generally encourage upstreaming new patches. I’d say it’s overall manageable. Also, I seem to recall (but don’t have evidences) the Rust project does similar light patching of LLVM as well, and probably other LLVM-based compilers do the same

[tecosaur]

@giordano

Yes, but they also provide tons of python packages in their repositories, in principle you’re supposed to install those, in practice good luck being able to use that single version of a package if you have multiple environments with conflicting requirements.

Just to give a sample from OpenSUSE Tumbleweed:

~$ zypper search python | wc -l
11627

~$ python3.12 -m pip install pillow
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try
    zypper install python312-xyz, where xyz is the package
    you are trying to install.
    
    If you wish to install a non-rpm packaged Python package,
    create a virtual environment using python3.12 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.
    
    If you wish to install a non-rpm packaged Python application,
    it may be easiest to use `pipx install xyz`, which will manage a
    virtual environment for you. Install pipx via `zypper install python312-pipx` .

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

@giordano

I don’t know what are the policies nowadays but trying to convince some of them to install juliaup may not be super easy

Oh, and just for fun, here’s the julia situation:

~$ zypper search julia
S  | Name                          | Summary                                        | Type
---+-------------------------------+------------------------------------------------+-----------
   | julia                         | High-level, high-performance dynamic program-> | package
   | julia-compat                  | High-level, high-performance dynamic program-> | package
   | julia-compat-devel            | Julia development, debugging and testing files | package
   | julia-devel                   | Julia development, debugging and testing files | package
   | juliaup                       | Julia installer and version multiplexer        | package
   | libjulia-compat1_10           | Julia shared object libraries                  | package
   | libjulia1_10                  | Julia shared object libraries                  | package

[mkitti]

I just want to boot into a BinaryBuilder-based environment with the Julia REPL as my default shell.