search

conda-forge / julia-feedstock

A conda-smithy repository for julia.
BSD 3-Clause "New" or "Revised" License
23 stars 32 forks source link

Switch to `juliaup` #256

Open MilesCranmer opened 1 year ago

MilesCranmer commented 1 year ago

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.
  2. Windows is not yet integrated https://github.com/conda-forge/julia-feedstock/pull/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

**

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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)