Mock label for "bring your own julia"

[mkitti]

Since we have put some effort into activate.sh to enhance integration between conda and Julia, perhaps we should consider a mock package the only delivers the scripts, but not the binaries.

The environment variables that we set would affect a Julia installed from another mechanism. juliaup is one example. This would allow us to provide the benefits of activate.sh while also allowing a wider source of Julia installs to take advantage of them. For example, this would help Windows users currently for which we currently cannot build Julia due to lack of dependencies or a modern MSYS2 build environment to use.

[mkitti]

@ngam Here's a proposal. On platforms that we cannot build for due to lack of prerequisite infrastructure, perhaps this feedstock should just depend on the juliaup-feedstock ?

[ngam]

I am not sure if core would allow such a thing, but yes, I think that's a good idea. What we can do is customize the call by juliaup (or jill) so that it installs the stuff within $CONDA_PREFIX. Then we can ensure all customization is done like for other platforms.

Let's try a protype? I have no access to windows machines (not sure about you) but I have access to M1/M2 macs. It will be, of course, quite difficult to have downstream packages depend on this in a neat way, so we may run into trouble and confusion...

If your thinking is motivated by M1/M2 availability, then let's hold off until the end of the year. There will likely be public CI for M1/M2 by then and conda-forge will start moving from emulation to native around then. For windows, I am completely out of my depth.

[mkitti]

What I'm looking for is a way to satisfy the "julia" dependency when we cannot build Julia for that architecture.