Repository navigation
Stop providing conda packages? #952
Description
Since #176 the openeo package is also installable through conda.
Question is if doing this is still worth the effort.
It adds additional maintenance overhead, typically just accepting some PR on https://github.com/conda-forge/openeo-feedstock, which is not that much when things work automatically, but when some PR related build is broken, I'm basically lost in tooling and workflow I have no experience with (I don't even use conda as a user).
e.g. there is currently some build problem for the release 0.53.0 (conda-forge/openeo-feedstock#48), and the error looks quite cryptic at the surface.
Regardless, I'm not sure how popular/relevant conda still is, now that uv is grabbing a lot of attention
And on top of that, I also noticed this notification in the error logs:
Did you know? You can install many PyPI packages with conda
using conda-pypi. Get started:
https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/install-packages-from-pypi.html
which is another reason to reconsider spending all the conda effort as the openeo package is a pure python wheel on PyPI that can be installed with new versions of conda as-is
Activity
soxofaan commentedon Oct 7, 2026
cc @sebastian-luna-valero
sebastian-luna-valero commentedon Oct 7, 2026
Hi,
Searching for
openeoin https://conda-forge.org/packages/ I found:If you click on those links you can see the number of downloads.
However, if you consider this to be non sustainable from your side, feel free and remove the conda packages.
soxofaan commentedon Oct 7, 2026
thanks, that's interesting info
I asked Claude to pour that in a quick graph:
which somewhat suggests a downward trend. Question is also how large the contribution of automated/CI builds is, compared to real users installing it manually.
Note that the maintenance burden is not necessarily the reason to stop doing it, but just the fact that recent conda version seems to support pure PyPI wheel installs, so what's the point of making conda packages in the first place then?
sebastian-luna-valero commentedon Oct 7, 2026
I recently bumped into this as well:
https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/install-packages-from-pypi.html
Indeed, it seems like a good direction to go.
Personally for me having the
conda-forgepackage has the added value that you get additional testing out of the box, which usually improves the usability of the code.I will let you decide what's the best option ;)
soxofaan commentedon Oct 8, 2026
@HansVRP @VincentVerelst @VictorVerhaert @Pratichhya are you aware of use cases or users that require the availability of conda packages over standard PyPI packages?
VincentVerelst commentedon Oct 8, 2026
No, I don't know of any use cases where PyPI wouldn't suffice.
HansVRP commentedon Oct 9, 2026
not immediately; could be good to do a sanity check with the devops team who created those predefined kernels for CDSE/Terrascope notebooks to avoid they are rely on conda while we mitigate away from it.
A similar check should be made with Isabelle/Katrijne or Jens for how they run cropsar within their service and maintain their libraries
soxofaan commentedon Oct 14, 2026
Good point. Reached out and they indeed use conda currently, but we created internal ticket GDPS-465 to follow up
jdries commentedon Oct 14, 2026
I also have some experience with very novice users trying to get openEO installed via conda;
For them, even using conda forge was already a challenge. Is the proposed alternative an improvement for that type of user or a regression?
soxofaan commentedon Oct 14, 2026
the conda install is documented at https://open-eo.github.io/openeo-python-client/installation.html#installation-with-conda
and the user facing part of the proposed change would be to replace
conda install -c conda-forge openeowithconda install -c conda-pypi openeoThis change is so small it can't be called an improvement nor a regression.