Larch 0.9.66 install which works on MacOS and WSL and is compatible with Jupyter

[joelager]

It took a long time to get a sequence of installs to work which would not create issues with Jupyter Lab.

Here is what finally worked

# Make a new environmment and activate it  
# Note that the command line prompt tells you what evironment you are in
conda create -n larch2023
conda activate larch2023

# Install the packages recommended on xraylarch site
conda install -y -c conda-forge wxpython pymatgen tomopy pycifrw
# There are two more actually
conda install -y -c conda-forge fabio cchardet

# This is so Jupyter lab can find the environment and run in it
conda install -y -c conda-forge ipykernel

# Finally the pip install of larch
pip install xraylarch

# Optionally, check the list of packages
conda list

Finally, the first time you use matplotlib you need cell magic %matplotlib inline

[maurov]

@joelager thanks for reporting this. It is true that more and more users (including myself!) work with Jupyter (Lab), so we should provide installation instructions for creating a correct environment for it.

We cannot put Jupyter as Larch dependency, but we can add more documentation and eventually propose specific friendly Python environments to work with Larch.

I have just seen #421 too, it is somehow related to this. If we want to work more with Jupyter, we definitively need a Jupyter-compatible plotting backend, independent of Wx (as was recently mentioned in #416). Matt and I were plannig using Plotly instead of Matplotlib. If you have human resources to help with this task, it would be great!

Going back to the Jupyter-friendly Larch environment. I have something like this: https://github.com/maurov/xraysloth/tree/master/binder. It is on my todo list to push an environment file for Larch too. Somehow related to #358.

In the meantime we could update the related documentation page by mentioning the required packages to install for running the Larch Jupyter examples correctly.

Few comments in the meantime:

• installing cchardet was mentioned also in #419 (just for cross referencing)
• is installing fabio with conda really necessary? normally it is pip-installable via the silx dependency of Larch
• why do you need to conda-install ipykernel? it would be better to keep it at the pip side

@newville do you think this is mainly a documentation issue or should we provide in the installation scripts an option to include the Jupyter environment?

[newville]

@joelager, @maurov thanks, and yes, I agree that we should do a better job supporting Jupyter, and especially plotting with Jupyter. Jupyter-specific install script or docs might be helpful.

Also: yes, cchardet was a horrible mistake on my part, and we will switch to using charset-normalizer.

For fabio, I also had some trouble with this from PyPI, with Python 3.11 anyway. I agree that "pyfai silx fabio" really ought to go together. Maybe that is a moving target?

[joelager]

why do you need to conda-install ipykernel? it would be better to keep it at the pip side

Good question. My goal was to use conda as much as possible and pip for the last step for the xraylarch install. I suppose this is because in the past (2021, the last time I taught the class) it was possible to install xraylarch completely from the GSEGEARS (?) repository on Anaconda. In any case, I was happy to find an install sequence which worked finally.

[newville]

@joelager @maurov yeah, on "conda" vs "pypi", I was (trying to) maintain conda packages for all these packages. I found it increasingly painful and sort of a time-sink. I do still help maintain some conda-forge packages, but I feel like the GSECARS channel is not really needed anymore. Most dependencies are available on PyPI, which is much easier to work with on both ends.

I definitely prefer to have Larch not require Anaconda Python. Aside from wxPython on Linux and "tomopy" (only available on conda-forge), using Anaconda Python really is optional.

That said, the "installers" that I maintain do start with Miniconda and use conda for much of the scipy stack -- this is what Anaconda is really good at. There is a claim that "mixing conda and pip is a bad idea", and I guess I'm willing to use Xraylarch as a counter-argument: Yes, I can see how problems could potentially arise, and, gee we don't ever run into such problems.

[maurov]

@joelager @newville I have tested (not on MacOS) a conda/pip installation recipe that nicely works on WSL/Debian and gives a Jupyter+Plotly compatible environment.

I include full track starting from the Mambaforge install because I would like to move to mamba (as described in #358) in the install scripts too.

wget https://github.com/conda-forge/miniforge/releases/latest/download/Mambaforge-Linux-x86_64.sh
sh ./Mambaforge-Linux-x86_64.sh -b -p $HOME/local/conda
source $HOME/local/conda/bin/activate
mamba create -n larch2023.3 python=3.9
conda activate larch2023.3
mamba install -y -c conda-forge wxpython pymatgen tomopy pycifrw jupyterlab ipywidgets plotly silx sqlalchemy
pip install git+https://github.com/xraypy/xraylarch.git

@newville it would be nice to uniform and stick to the same list of "non pip" requirements everywhere. In fact, now there is currently discrepancy among the documentation, install scripts and workflows scripts.

By the way, I think mixing conda/mamba-(forge) + pip is the good way to go.

[newville]

@joelager @maurov For reference, I have tested (and mostly developed) the plotly plotting code on MacOS, as well as Linux and Windows. It is still a work in progress, but I think is enough of a working prototype for comments and further exploration. I don't have a great understanding of how the rendering is actually decided, for example, what happens when using it outside of Jupyter - say a plain Python REPL. And I have not tried colab or binder or other approaches.

I'm +1 on using mambaforge and intend to convert the "GetLarch" scripts to use that "real soon now". I am resigned to needing mamba/conda + pip for default installations for a while (at least until wxPython for Linux is pip-installable). And there is one optional scientific package (tomopy) that is, unfortunately, only available from conda-forge.

There is a definite case to be made for trying to get to "pip only", or "system-provided Python + pip", and it's not impossible. I would be happy to not have to depend on Anaconda Python.