Closed xavpaice closed 4 years ago
This is due in part to the isolation from the snap meaning the the python3-dev
packages from the host system can't be accessed. @knkski did hit this with a different library, PyYAML, on Travis, and was able to work around it by removing libyaml-dev from the host, but this seems like a different package and that doesn't seem like an ideal general approach.
Another way you could work around this is to move the cffi
library from the wheelhouse.txt
to the python_packages
layer option for layer:basic
. This would defer fetching, installing, and building until deploy time.
I am also confused why, with the charm build, the pip download
command somehow got turned into a pip install
command. We specifically don't want it installing or compiling anything locally, since the generated artifacts may end up on other architectures and should thus be compiled at install time.
I briefly considered adding python3-dev
to the snapcraft.yaml
, but that seems like a mistake since we don't want compiled binaries embedded into the charm in any case.
@johnsca
I agree that avoiding any compilation at the build machine is preferable, otherwise we are creating arch-specific charms which is what usage of python is meant to avoid.
The code in question seems to be quite old though.
Have you come to any conclusion on how to approach this problem?
I'm running into this issue as well when trying to add python-libmaas to wheelhouse.txt to support not only the charm's code being able to create a user within MAAS, but also a custom nagios plugin which uses that user to query status of MAAS services.
The point about not having compiled binaries within the charms makes sense unless the charm is specifically to be run on an amd64 ubuntu host running our MAAS product, for instance.
Is there some way to detect and provide warnings during charm build phase that would notify users that they're adding a compiled bit that will necessarily lock their charm into a specific architecture while allowing for the technology to be used in situations where it is warranted or safe to do so?
Using python_packages in layer:basic won't work when using venv=true in order for charm-landed scripts to function outside of the context of the charm.
In environments where they are detached from the internet, using 'pip3 install python-libmaas' will not be a suitable solution.
I will note regarding pip install vs. pip download, the latest version of charm tools does run pip download:
Command failed: bash -c . /tmp/tmp_00ct2c4/bin/activate ; pip3 download --no-binary :all: -d /tmp/tmpppxdjrnp -r /home/drew/layer-infra-node/src/wheelhouse.txt
The issue with all of these pip packages has the common thread of requiring cffi, which is the C Foreign Function Interface for Python, which necessarily needs to be compiled for the architecture(s) being supported as it allows python to interface directly with shared libraries. Any packages in wheelhouse that require this functionality are going to fail in charm building.
Oddly, there are packages python(3)-cffi-backend within the ubuntu repositories which are able to install this pre-req, but that does not get referenced as an available library during the pip(3) download as an available/pre-installed package.
I did notice that my gcc command was including some system library locations that didn't exist and I created a symlink from one of those to work around this issue:
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/usr/include/ffi -I/usr/include/libffi -I/snap/charm/357/usr/include/python3.6m -I/tmp/tmphnu01ki2/include/python3.6m -c c/_cffi_backend.c -o build/temp.linux-x86_64-3.6/c/_cffi_backend.o
Since /usr/include/ffi did not exist, I hijacked this path to land a symlink to /usr/include/python3.6m which solved this for me. I will make a special note in my charm README that this is specifically intended for amd64 systems as it may break python-libmaas on other platforms.
The point about not having compiled binaries within the charms makes sense unless the charm is specifically to be run on an amd64 ubuntu host running our MAAS product, for instance.
The issue isn't with packages requiring compilation being used in the wheelhouse, per se, because only the package source is actually bundled (which would then be compiled and installed during bootstrap on the target unit). The issue is that pip download
internally uses the installation code-path to fetch and resolve dependencies which ends up trying to compile the packages within the charm
snap environment, which doesn't include any of the build dependencies (and would almost certainly always be missing some for an arbitrary package). If we could avoid / prevent pip from doing the "dummy install" during pip download
, then including packages requiring compilation in the wheelhouse would be a non-issue.
Another option might be to have the build process create a snapped "charm runtime" (we'd still want to keep the charm code itself outside the snap to make interactive debugging easier) and automatically include that as a resource. However, that runs up against the architecture-specific resource problem. But possibly the new charm store could handle that in a clean and graceful way.
I've run into the same issue when wheelhouse.txt
looks like:
psutil pylxd
I applied the same workaround mentioned by @afreiberger, which is take advantage of the included /usr/include/libffi (which didn't exist) and link it to /usr/include/python3.6
sudo ln -s /usr/include/python3.6 /usr/include/libffi
Another workaround (for openstack charms at least) is to install libffi-dev locally and build via the openstack charmers scripts instead of using the charm snap
Another workaround (for openstack charms at least) is to install libffi-dev locally and build via the openstack charmers scripts instead of using the charm snap
Did you mean to link to https://github.com/openstack-charmers/release-tools ?
Another workaround (for openstack charms at least) is to install libffi-dev locally and build via the openstack charmers scripts instead of using the charm snap
Did you mean to link to https://github.com/openstack-charmers/release-tools ?
I did! Fixing...
What version am I running?
I ran the following command:
snap info charm
and got the following output:I am using: Ubuntu Bionic
Issue
When running
charm build
on my charm, the dependencies fail to compile and build fails as a result.This shows up when I have a charm that has the following in
wheelhouse.txt
:I expect/expected the following
charm build --no-local-layers -v
should complete without error. If I remove cffi and openstacksdk from wheelhouse.txt it's all fine, even if I put different packages there.What I got
Out of interest, I tried running the failed command in a virtual env on my box: