Sooo I have a weird problem with our pants migration... Currently I am using libcamera and unfortunately all of the bindings and shared libraries need to be built from scratch (Currently working with the maintainers to figure out a release process but that is awhile off as FOSS). At the end of the day, meson+ninja does the build of C+ and python bindings.. but it only puts the python bindings into the local host site-packages. In our current world, we are using Make and we do this nasty blob to copy things from site-packages into a virtual environment..

$(SITE_PACKAGES)/libcamera/__init__.py: pyenv-virtualenv requirements-libcamera-deps /usr/local/lib/x86_64-linux-gnu/libcamera.so
	rm -rf .lc_build_temp
	mkdir -p .lc_build_temp
	cd .lc_build_temp \
		&& git clone <https://github.com/Exclosure/libcamera.git> \
		&& cd libcamera \
		&& git checkout v0.0.4 \
		&& PKG_CONFIG_PATH=$(PKG_CONFIG_PATH) meson setup build -D pycamera=enabled \
		&& ninja -C build \
		&& echo "Copying libcamera to venv" \
		&& cp -Lr ./build/src/py/libcamera $(SITE_PACKAGES)/libcamera
	rm -rf .lc_build_temp

Gross I know, but.. yeah. So question: Is there a way to have pants look on the local host for packages else where? Can we use third party dependencies local requirements in a creative way? Unfortunately, the built package is not a wheel or sdist.

Gross indeed! So it's building into the interpreter's non-virtualized site-packages? Thus dirtying the interpreter?

Essentially 😕

Not sure I understand the scenario

Make hacks like above...

But how do you deploy to a system other than the one you built on?

We build container images doing this magic during docker build

aha

mmmmm that is an interesting idea

That can run arbitrary commands and place the outputs in the next command's sandbox

How could we utilize the generated files on site package as inputs that could be imported in a python module. 🤔