Discussion of the future of berryconda

[jjhelmus]

It has been a long time since I've made any updates to this GitHub repository and it is time to make it official. Berryconda is no longer active, I will not be updating recipes nor uploading new packages in the rpi channel.

That said there seems to be interest from others in the community to continue building conda packages for the Raspberry Pi. Hopefully those who are interested will join the discussion in this issue and determine a path forward.

[step21]

Hi @jjhelmus thanks for the update!
For my part, I have replicated building packages and berryconda installers locally, and might have worked on packaging this into a docker environment for automation.
What am I missing? Mostly I am not very familiar with how conda channels work - I think I could just host my own channel, but that is probably not an ideal solution. So from my point of view, ideally I would commit new recipes to this repo (or fork it) and then new packages would be uploaded to rpi channel (or a similar channel). Would that be possible? Do I need my own hosting for that?

[jjhelmus]

@step21 Glad to hear you are interested in helping move Berryconda forward. Let me try to give some background on channel and such.

My workflow in the past was to build packages on one of my Raspberry Pi's and then upload to the rpi channel using the anaconda upload command. The anaconda-client package provides the anaconda upload command.

Anaconda Cloud, anaconda.org, provides free hosting of conda packages. Anyone can sign up for an account and either upload to the channel associated with their username or create a organization with a different name. The later is how the rpi channel is set up.

Since this repository is under my personal GitHub account I would prefer that future development occur in a fork. I've happy to point to that fork in the README.md file and description of this repository.

One thing to keep in mind is binary compatibility. conda-build 3 has a number of features that help with binary compatibility but the Berryconda recipes do not make use of all of these.

In the past, I've built packages on systems with an older install of Rasbian for better compatibility with older glibc versions. Another option would be to use compilers with a sysroot containing an older glibc version. This is how Anaconda Inc and conda-forge build packages which work on most Linux distribution. I did some work along these lines in the conda4armv7l repository which may be of interest.

[mathematicalmichael]

is that conda4arm repo meant to be a replacement for berryconda? I'm not sure I understand the differences between the two.

Thank you for opening up this dialogue. There's so much to be done in terms of making the pi more usable for pythonic computation and good packaging is integral.

[jjhelmus]

The conda4armv7 repository was an experiment to see if a Miniconda-like installer could be created for a general purpose 32-bit ARM platform. Specifically, compatibility with Debian's armhf port was desired. This experiment used compilers built by conda-build and provided as conda packages which mirrors how Anaconda, Inc and conda-forge build packages for x86_64 Linux.

This experiment followed the conda4aarch64 project which did the same for a 64-bit ARM which was then used to bootstrap support for this platform in conda-forge.

This experiment was a success, the repository has a Miniconda-like installer in the 1.0.0 release which was build from the packages in the c4armv7l channel. This installer and packages will work on most modern 32-bit ARM systems including Raspberry Pi models 3, 4 and likely 2. This work could be used as a starting point to create a replacement for berryconda but this this not something I am pursuing.

I gave a talk on this topic last summer at the 2019 Arm Research Summit, the slides for which are available

[step21]

Hey. So I did a testing 'channel' here - https://anaconda.org/rpix/repo
It is very untested and is missing packages, since not everything builds yet. Repository with some updated recipes and build scripts is here https://github.com/step21/berryconda/ - testing welcome. (just packages, no conda builds yet though)

HOWEVER - unless there are some drawbacks that I am not aware of, personally I am also testing my stuff on (Ubuntu) AArch64 right now, and if that works out, I will just switch to that, as I do not see a need to run on Raspbian or support 32 bit, just because Raspbian still uses that. (building itself actually is automated more or less and not that slow on a Raspi 4 - however quite a few recipes are in need / will need changes.

[mathematicalmichael]

@step21 awesome, thanks! what are the implications if one was to try to use berryconda on a Pi Zero, for example? Would it still work but just be slow because of lack of wheels (if that's the right vocab)?

[step21]

Probably everything on the Pi zero is slow. It is also armv6, which I do not have and do not plan to support. (armv7l might work, might not depending on package from what I know)
So it probably will not work, it might work with the original berryconda installer and rpi/rpix channel. But given the constrained circumstances of the hardware and depending on what you want to do, I would suggest not using conda unless you have a very good reason why you need it. For me, the reason is to have more up to date packages to replicate jupyter-docker images and also have a good way to install R-Packages etc that doesn't require manual install or adding ppas or similar. So far this doesn't work on ARM yet, but at least in theory it can. Either way, I am more interested in more performant uses.
(also, wheels are what pip uses, conda just says packages afaik)

[step21]

To get some more input for this - what would be a reason fro @mathematicalmichael or other to use berryconda/raspbian on anything that supports aarch64? For me at first it was also simply not knowing about it, not knowing raspbian was still 32 bit.
If there are good reasons, I might try to support the new rpix channel, otherwise I would suggest everyone moving to conda-forge. There are some packages still missing there as well but much less, and more people working on it, so it will be less work in the end and more satisfactory for most.

[mathematicalmichael]

To get some more input for this - what would be a reason fro @mathematicalmichael or other to use berryconda/raspbian on anything that supports aarch64? For me at first it was also simply not knowing about it, not knowing raspbian was still 32 bit.
If there are good reasons, I might try to support the new rpix channel, otherwise I would suggest everyone moving to conda-forge. There are some packages still missing there as well but much less, and more people working on it, so it will be less work in the end and more satisfactory for most.

yeah I'm starting to realize just how limited the hardware is. I have a pi 4B+ that I could maybe justify running jupyterlab via docker image on, are you saying that regular conda-forge supports that architecture?

my use case is something along the lines of.. I've been building docker images on x86 and have used conda for a number of them (though generally have been moving towards pip + manually handling the dependencies in Clangs). It would be nice to be able to port the images directly by simply rebuilding on arm, but I'm starting to also realize that the overhead of containerd running isn't really worth it. challenging installs like scipy can still be pulled off using apt in raspbian, it seems.

In short, after playing with these machines, I'm starting to come around to realizing I have to approach how/what I use them for differently than my other machines. It can definitely take the place of doing inference and data collection tasks, but I don't think training models on them will be a good use of time, which is what I was sort of experimenting with when trying to set up my scientific compute environment. The dream was live data collection from GPIO + live inference on the chip.

[step21]

I run jupyterlab on Raspi 4 and 3B+, with docker. Not all packages are available yet, but probably more than on rpi / rpix channel. Installer is here https://github.com/conda-forge/miniforge/ - website is here conda-forge.org/

are you saying that regular conda-forge supports that architecture?

yes. You only need to be running an aarch64 based system like Ubuntu instead of Raspbian. (as it is not yet 64 bit, but they are working on it I think)

but I don't think training models on them will be a good use of time, which is what I was sort of experimenting with when trying to set up my scientific compute environment. The dream was live data collection from GPIO + live inference on the chip.

This depends very much on your models and data. I think the raspi 3/4 can def handle at lot, especially the 4. Or another board with specific ML support, though maybe you cannot take advantage of that w/o custom packages anyway not sure.

[moi90]

Did you manage to "determine a path forward"? What is currently the best way to install scientific python packages on the Pi Zero?

[step21]

Did you manage to "determine a path forward"? What is currently the best way to install scientific python packages on the Pi Zero?

If you mean me, I decided it's not worth it, as it's a lot of work and I think you cannot reasonably run most scientific python packages on this limited hardware anyway. (In a reasonable way) And why would you want to?
And if you need just one or two packages, just use pip or what you distribution provides. (That's what I would do) This might be difficlt for specific packages - but chances are these are also the most pain to compile in any packaging, and chances are even if they are in theory supported on such different or limited hardware (not all are) then they will run like crap anyway.

[moi90]

I see, thanks!

[step21]

Instead, I opted to support @conda-forge (conda-forge.org) with packages, as I updated all my machines to arm64.
I hope you find a way to make it work for you! (if you let me know about specific needs I might be able to point you in the right direction)

[moi90]

Does conda-forge contain armv6 builds?

[step21]

No, they only added support for arm64. I found this. conda-forge/conda-forge.github.io#269
Using docker it's probably possible, but seeing as apparently even raspi2 was already armv7, I do not have high hopes for someone putting in the effort for armv6. (and depending on which packages you want, I think they might fail anyway/are not supported by upstream)

[deeplook]

@jjhelmus Just curious if anything has changed from your side or from Anaconda's given that ARM has now the one prominent new user that Anaconda always wanted to have (Apple) in order to support the Raspberry Pi ecosystem better?

[step21]

@deeplook this was always about armv6/v7 etc as that was what was targeted by Berryconda, and Apple using arm64 does not change that. Support for arm64/aarch64 has since some time been better/easier to build, especially thanks to conda-forge. Still, with osx-arm64 conda-forge has an * additional * compilation target. So supporting arm on mac and arm on linux is actually more work, but still this does not mean that it will work on 32 bit arm on linux.