Installing astronify at the Rubin Science Platform in `data.lsst.cloud`

[plazas]

I'm trying to install astronify at the Rubin Science Platform (RSP) in data.lsst.cloud to create a short Jupyter Notebook demonstration on how to use astronify with LSST-like data.

At first, pip install --user astronify would run into problems with portaudio (the details are in this public forum question: https://community.lsst.org/t/installing-astronify-via-homebrew-on-rsp-notebooks/8066). A colleague from Rubin suggested doing a minimal installation of pyo to exclude portaudio since portaudio is used when you want to play audio on the same computer that you’re running the code on, but on the RSP the code runs in a data center somewhere, so instead you need to use IPython to interface with the browser to play the audio. This solution worked fine as of November of 2023, but now the following error message appears when trying to import astronify in a notebook:

ImportError: libsndfile.so.1: cannot open shared object file: No such file or directory

A colleague from Rubin suggested that astronify might be out of date with respect to the astropy built into rubin-env, which has astropy 6.0.0..

[scfleming]

@plazas another user reported an error with Astronify and astropy v6.0.0. If the error being seen is related to this:

ImportError: cannot import name 'update_default_config' from 'astropy.config.configuration'

Then that matches another user error, and is indeed due to something that is no longer supported in Astropy 6.0.0. It should be doable to remove this from the Astronify setup.py and get it to work with Astropy v6.0.0, so I'll work on that as soon as I have some spare time. In the mean time, and if it's an option, you can try to run Astronify in an environment with an older version of Astropy installed, like 5.3.4

[plazas]

Thank you, @scfleming! The error is different, though. After doing import astronify I get an error like the following: ImportError: libsndfile.so.1: cannot open shared object file: No such file or directory I installed a previous version of astronify (5.3.4) just to see, but I still get the same error.

[scfleming]

OK sounds like you don't have the necessary non-Python package files installed. Have you done these steps (if on a Mac)?

1.) Install homebrew 2.) brew install portaudio 3.) brew install portmidi 4.) brew install libsndfile 5.) brew install liblo

Then you can try to pip install pyo and/or astronify:

pip install pyo pip install astronify

If you are on a newer Mac there are some c-compiler options that can assist with the brew installs, let me know if those give you an error or not.

[scfleming]

If you do have those brew packages installed, it's possible pip is looking for them in the wrong spot since the default locations have changed between different versions of software/OS. If still having issues, try this:

• Add the following to your shell of choice (I use .cshrc so the example is for that, if you use bask change syntax appropriatly and put in your .bashrc file or equivalent) setenv CFLAGS '-I/opt/homebrew/include/' setenv LDFLAGS '-L/opt/homebrew/lib/'

and then try to pip install pyo and/or pip install astronify

[plazas]

Thank you! I'm not sure I can use something like Homebrew to install the packages. I am not trying to do this on my own Mac, but at the Rubin Science Platform at data.lsst.cloud. The RSP the code runs in a data center somewhere. I can try and double-check if I can perhaps locally install those packages, is there something other than homebrew that could be used? As mentioned in my original post, last year things were working for. me as long as I tried a minimal installation of pyo that excluded portaudio. Now the error seems related to libsndfile instead, so perhaps that's what's missing? I think I looked into installing it locally in my home area at the RSP, but perhaps I found it was non-trivial. My end goal is to write a short demo tutorial to show users how to sonify LSST data (using simulations for now), and I wanted to use astronify.

[scfleming]

Ah in that case, try making the change to the CFLAGS and LDFLAGS then, since that might solve the issue where the pip installation is looking for the libraries in a different location. Actually, to be 100% sure, you'd want to make sure those environment variables are pointing to wherever those libraries are actaully installed in the science platform, otherwise pip install pyo will give you that error because it won't be able to find those C libraries it needs.

I don't think you'd be able to install pyo without (most) of those libraries available, however the science platform can install them. If none of those are available, then pyo won't install and neither would astronify.