Switch to juliaup

[MilesCranmer]

I am wondering if this feedstock can switch to a juliaup-based distribution on conda forge? Here are the reasons for doing so:

1. Apple is completely switching their computers to Apple silicon, so I think it is important we get osx-arm working.
   • However, Julia does not support cross compilation, so we can't ever build it on the osx-64 worker, despite the multiple attempts to get it working (Adding osx-arm support #224, Adding osx-arm support v3 #252).
   • There are no M-series workers available for conda-forge.
2. Windows is not yet integrated Initial Windows build attempt #168, and seems difficult to get working.
3. Significantly lower maintenance burden.

What do you think @mkitti @ngam @staticfloat @stevengj? How hard would it be to switch to juliaup? Are there any attempts at doing so?

[MilesCranmer]

There is this feedstock: https://github.com/conda-forge/juliaup-feedstock. I guess one option is to depend on that feedstock, and use it to install a specific julia version?

[mkitti]

What @ngam and I discussed in the past is creating an alternative label for this. I'm not sure how to do this myself at the moment.

Perhaps another solution is to just put this in another conda channel that is not conda-forge. julia-forge?

[ngam]

This would be akin to "binary repackaging" and usually it is highly not recommended in conda-forge. However, your points are valid and that's why we discussed doing this in the past. A few pointers:

• Firefox-feedstock: https://github.com/conda-forge/firefox-feedstock
• How CUDA-related tools used to be repackaged (things changed recently, but likely at least some of them are still being repackaged)
• How Intel-related tools get repackaged: https://github.com/conda-forge/intel-compiler-repack-feedstock

**

I believe the bigger problem with Julia (in this feedstock here) is that in the future we want interoperability between shared libraries and that's pretty difficult to achieve. I also am not entirely sure we will be able to get to a consensus about how to fully package and distribute Julia packages in conda-forge ecosystem anytime soon. I am bringing these issues up to actually support binary repackaging (i.e., what you're proposing). We are building Julia from source by doing a lot of work, with no particular value because we cannot take this source-building further...

[mkitti]

I'm not absolutely sure it would be binary repackaging because we might end up downloading Julia from the user's computer instead of during build. Instead we might just install an activate script that would ensure the correct Julia version is enabled.

[mkitti]

@ngam would it be easier to provide an alternate label here or just upload this to a different channel?

For the label approach, could you point me to the documentation.

[MilesCranmer]

You know how you can install pip packages in a conda environment with:

dependencies:
  - ...
  - conda-forge::pip
  - pip:
    - my-pip-package1
    - my-pip-package2

I wonder if we could do something similar with Julia?

[ngam]

To make a wrapper package to install Julia via juliaup, right, @mkitti?

I think we can start with a label here if you prefer, but ideally, it should be migrated elsewhere. Things will be much slower to migrate elsewhere, so it is easier to just do it here first imo to see how far one could get. Recall, we already actually do this in our dev branches. See how dev or rc branches. In particular, you just need

channel_targets:
  - conda-forge julia_dev

in recipe/conda_build_config.yaml for the dev branch. I am not sure if we have better docs than this bit: https://conda-forge.org/docs/maintainer/knowledge_base.html#creating-a-pre-release-build. I would encourage you to experiment in the dev branch if you'd like. Or open a PR against the dev branch and edit. I will have a look as needed. Making a totally new branch is also okay (e.g., if you prefer a different name than dev); just make the edit as above and rerender then push into a new branch (or I can do it too)