Use pixi (attempt 2)

[cisaacstern]

A fresh take on the work in #220

[cisaacstern]

I am very happy where this is, and definitely see this as the basis for the path forward.

Next steps (as PR's on top of / following on this):

• Move example builds to build dirs and package them with their own pixi.tomls so they can run their own tests, xref ecoscope-workflows compile command should generate a build directory (not just a single artifact) #216
• Build docker images for each of those specific builds. At this point those containers will likely look the same (so we can maybe check a key of some sort and skip build if it exists or something). But in principle this matters a lot as there is not just one worker container. Each workflow is potentially its own image (with a different pixi env). xref Use pixi.sh instead of micromamba #220 for the base image for this.
• Docker images include base images, lithops worker images, and script runner images. Once we have one each of these three for all of the example workflows, then we can close the book finally on Build worker container with custom conda channel #214 (but from this new angle).

[cisaacstern]

More TODO:

• In merging Map legends #223 I realized that the existing vendor version check doesn't sufficiently capture possible changes to the dependencies of ecoscope and/or lithops ... lonboard fork is bumped to 0.0.3 and we are not catching that in CI. Add some mechanism to prevent this going unnoticed.

[cisaacstern]

🤔 @atmorling I was really struggling to get the tests to pass following merge of #223 and ultimately found I needed this change to avoid the error

FAILED tests/tasks/test_ecomap.py::test_draw_ecomap_with_legend - traitlets.traitlets.TraitError: The 'colors' trait of a LegendWidget instance contains an Unicode of a List which expected a unicode string, not the tuple (0, 255, 0, 255).

Does this change seem ok? i.e.

colors=[str(lc) for lc in legend_colors],

instead of

colors=legend_colors,

And if so, any idea why tests were passing on merge of #223 but not here? I really don't think I've changed anything that would touch this 🫤 ... unless the vendored conda edition of lonboard has a some dependency version difference that matters?

[cisaacstern]

unless the vendored conda edition of lonboard has a some dependency version difference that matters?

All CI dependencies for this PR are listed in the lockfile, e.g. for one of the test envs on which I was getting the Traitlets error, packages are listed here:
https://github.com/wildlife-dynamics/ecoscope-workflows/blob/fe1d1ba64722ddd4f0f56306663de8e40b80d968/pixi.lock#L7392-L7403

[atmorling]

• conda: https://prefix.dev/ecoscope-workflows/noarch/ecoscope-v1.8.3-pyh4616a5c_5.conda

Just looking at pyh4616a5c_5 build, it looks like that was done against v1.8.3 of ecoscope and not the latest in master (which is what #223 points at). It looks like pyh4616a5c_4 was actually built from the "correct" git ref (basing this off the version of the lonboard fork)

In any case this all probably stems from the fact that #223 links to a commit rather than a tagged release, this was to streamline for demos and not something I intend to make a habit of.
I've tagged v1.8.4 which should reduce the headache.

[cisaacstern]

Thanks for these insights! I'm now tracking this in #244