Add a conda install option for alibi

[sugatoray]

A conda installation option could be very helpful. I have already started working on this, to add alibi to conda-forge.

Conda-forge PR:

• Adding alibi and alibi-detect from PyPI conda-forge/staged-recipes#17582

Once the conda-forge PR is merged, you will be able to install the library with conda as follows:

conda install -c conda-forge alibi

💡 I will push a PR to update the docs once the package is available on conda-forge.

[jklaise]

Thanks for the effort!

One thing I'm conscious of is the limited support of optional dependency semantics by conda as detailed here. We use optional dependencies fairly liberally (e.g. shap is currently optional) and plan to make even more use of this pip feature soon (e.g. making tensorflow optional). My understanding is that if we currently wanted to mirror the pip functionality on conda it would involve releasing multiple packages on conda which could place a heavy maintenance burden. I'm guessing the main alternative is to just support the "base" version of the package on conda and any extra dependencies would have to be installed by the user manually (e.g. conda install -c conda-forge shap instead of pip install alibi[shap]. This has the downside that we can't provide version bounds of the optional dependencies in conda which may result in a broken installation in some cases.

@ascillitoe @mauicv keen to hear your thoughts.

[jklaise]

So it seems that conda does support enforcing version bounds on optional dependencies when a user manually installs those: conda/conda#4982. This would support the a subset of pip functionality. However, grouping semantic parts of dependencies in extras (e.g. pip install alibi[nlp] where nlp might be a set of text processing dependencies) remains unsupported.

[ascillitoe]

Yes thank you for this @sugatoray!

That's a good point re optional dependencies @jklaise. Just to check my understanding, with conda 4.4 a user would still have to do something like conda install -c conda-forge alibi tensorflow, but we can now set the new run_constrained field to constrain the tensorflow version. Is that correct?

Not being able to group dependencies i.e. nlp is unfortunate, but one way around it might just be better installation instructions in the docs. I have in mind pytorch's installation instructions (https://pytorch.org/get-started/locally/). We could have tabs for pip/conda etc, and then tabs for tensorflow/pytorch backend, optional nlp support etc, to end up with the correct conda command like conda install -c conda-forge alibi=0.6.3 tensorflow=2.7.0 nlp=....

[jklaise]

@ascillitoe on the first point, yes, that's my understanding of the feature.

On the second point, definitely agree with explicit installation instructions as we modularise the package a bit more. Maybe it would be enough, but certainly not as automated as the pip approach (will also need to raise relevant errors if a user tries to use a component with missing dependencies - though TBD if we even expose those classes if the dependencies are missing).

The main think I'd like to avoid is maintenance overhead for conda so would try not to go down the meta-package route as it seems more hassle than worth it and possible divergence with pip dependency semantics.

[ascillitoe]

Just to add a bit more food for thought here. I think when thinking about conda vs pip (not that we have to choose one), its important for us to keep in mind that the pip workflow is not actually as automated as we sometimes think when working with GPU's. i.e. I'm not actually sure pip install alibi[pytorch] is a good idea here, as there's a reasonable chance that would end up with the wrong pytorch being installed for a user's cuda stack. In reality when using pip we should probably instruct users to first install pytorch, check it works, and then install alibi. For example:

pip install torch==1.10.1+cu113 -f https://download.pytorch.org/whl/cu113/torch_stable.html
pip install alibi

Conda would hopefully improve things quite a bit here since the desired cudatoolkit can be installed within the conda env. For example:

conda install pytorch alibi cudatoolkit=11.3 -c pytorch conda-forge

(might have the channel syntax wrong here)

[ascillitoe]

Looking at the tests for @sugatoray's PR, it looks like the Windows platform one is currently failing due an issue with the tensorflow and pytorch deps (link)? pytorch is coming into it via transformers, which I'm surprised about as I didn't think transformers set pytorch as a core dependency (perhaps something to look into wrt our modularisation work, as currently we were planning to have pytorch optional but transformers core).

I'm sure the above is fixable, but it does make me wonder if it's worth holding off on this exercise until we've completed the modularisation work and finalized our updated core vs optional dependencies. It depends on how much work it would be to update the conda recipe later, @sugatoray probably knows more wrt to that!

[sugatoray]

Both recipes of alibi and alibi-detect are noarch (architecture independent). So, all that is necessary, is a successful Linux build. Once a noarch package is available on conda-forge, when you try and install it, if you don't have a certain dependency available on conda-forge, you could install that from a different channel as well.

For instance, if you want to install it on Windows, the following should work.

# first install pytorch from another channel
conda install -c pytorch pytorch 

# then install alibi and alibi-detect
conda install -c conda-forge alibi alibi-detect

This is happening because pytorch is not available on conda-forge for Windows. But it is available for OSX and Linux.

So, in a nutshell, this doesn't pose any challenges for the user.

cc: @ascillitoe @jklaise

[ascillitoe]

Hi @sugatoray, that makes sense, thanks for the explanation. Thinking more about our dependencies I think we're fine to go ahead with this now, as can't actually see any major issues with our plans to change core vs optional dependencies in the future (and we can always deal with that later anyway).

Just one thing, would it be possible to add a few of our dev team as recipe-maintainers in the conda-forge PR please? ID's would be @ascillitoe, @mauicv and @jklaise. I think we would then need to comment on the PR to give "permission"?

Thanks again for your work on this, getting a conda recipe up and running will be a great help for our users 🙂

[sugatoray]

That's what I was about to suggest (to add one or more co-maintainers from here) 😊. I always prefer having devs/maintainers of the library itself, on the list of maintainers on the conda-forge recipe. This enables to release both PyPI and conda-forge more or less synchronously.

Is there anyone you suggested, who has previous experience with conda-forge packaging or maintaining a package (feedstock) on conda-forge?

If not, I can walk you through. It is fairly simple when it comes to maintenance. Typically, you only have to update a couple of fields in an yaml file (recipe: meta.yaml).

cc: @ascillitoe, @mauicv and @jklaise

[ascillitoe]

I don't believe any of us do actually, but keen to learn! I've had a brief look through the conda-forge docs and they look pretty comprehensive, but a walkthrough would be wonderful 😀. p.s. could we also add @arnaudvl to the list please?

[jklaise]

I have some knowledge as I actually attempted to make a conda package previously, but ran into some tensorflow issues which don't seem to be happening anymore: conda-forge/staged-recipes#12953.

[ascillitoe]

Ah apologies @jklaise!

[sugatoray]

@ascillitoe Sure. I don't have any reservations on adding maintainers. But, I would suggest to keep the number of conda-forge maintainers to a reasonable list of 2-4, who would actually be involved in keeping it updated. If anyone else is interested in updating the recipe, that's easy. All you need is a pull request to the feedstock with the intended changes.

[jklaise]

@sugatoray that makes sense, I would suggest myself and @ascillitoe then, thanks!

[sugatoray]

cc: @jklaise @ascillitoe

alibi is now available on conda-forge channel. 🎉

[sugatoray]

❓ Command to check version and avilability of alibi on conda-forge channel.

$ conda search -c conda-forge alibi
Loading channels: done
# Name                       Version           Build  Channel             
alibi                          0.6.3    pyhd8ed1ab_0  conda-forge         

[sugatoray]

@jklaise Please see this PR. I will push a similar PR for alibi as well.

• Add conda installation to docs/readme alibi-detect#440