Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce the environment builder API and implement a micromamba-based build handler #6

Merged
merged 121 commits into from
Sep 25, 2024

Conversation

ctrueden
Copy link
Member

This branch adds the logic needed to build conda environments from an environment.yml file, by downloading and calling micromamba in a subprocess. It does not yet support composing environments from multiple YAML files, nor declaring environments package by package. But it does provide a general and extensible API for more environment build handlers in the future, such as a builder that fetches and installs Maven artifacts, or one that installs packages from node.js.

There are three kinds of events possible:
* Progress update on some action - e.g. a file download
* Output message - e.g. the stdout stream of a micromamba invocation
* Error message - e.g. the stderr stream of a micromamba invocation
So that every single build doesn't need to download and unpack
micromamba, then download and unpack all conda environment packages.
Yeah, I know it's failing because it's using the system python on the
system path. I guess ProcessBuilder does that, similar to a shell.
But I wanted to add the debug output just to be friendly and clear.
The question is: how do we configure ProcessBuilder not to do that?
This sidesteps the thorny issue of environment activation within the
same process, in favor of micromamba activating+running the desired
worker launch command within the correct environment prefix, such
that activation scripts get sourced properly beforehand.
Just a succinct shorthand for subscribing to progress,
stdout, and stderr, printing all the events coming in.
Only inject micromamba config (`mamba run -f ...`)
launch args if the Appose environment is a conda one.

And clean up the no-pythons-to-be-found-here directory on exit.

This fixes the ApposeTest#testServiceStartupFailure.
Yellow for stdout, red for stderr.
@ctrueden
Copy link
Member Author

I'm looking for feedback on the builder's API design. If no one has time to take a look and comment within the next couple of days, I'll probably just go ahead and merge. But if you have time to take a quick peek into ApposeTest.java and the Appose and Builder API in general, I'd appreciate any feedback!

On macOS, the size of the allocated shared memory block might not
precisely match the request. But it needs to be at least as large as
the requested size. E.g.: sizes less than 16384 round up to 16384.

You might think it would be a good idea to make the size() method
of SharedMemory return the actually requested size, rather than the
weird rounded up size, but that's how it works on macOS on Python,
and we're trying to make the Java implementation match the Python
behavior as closely as possible, so... ¯\_(ツ)_/¯
@ctrueden ctrueden merged commit b7a4620 into main Sep 25, 2024
3 checks passed
@ctrueden ctrueden deleted the env-builder branch September 25, 2024 14:39
@ctrueden
Copy link
Member Author

Tests all passing on all platforms. I would still value API design feedback from @carlosuc3m @tpietzsch @hinerm and anyone with time and interest, though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants