Can't install in Alpine environments

[apiri]

• Nipyapi version: 0.8.0
• NiFi version: N/A
• NiFi-Registry version: N/A
• Python version: 3.6.5
• Operating System: (Alpine, specifically Docker image python:3-alpine)

Description

Describe what you were trying to get done, or what you would like the package to do. Tell us what happened, what went wrong, and what you expected to happen.

Was attempting to use the library in a Docker image and opted originally for the Alpine variant. Confirmed that Debian based variants of python image seem to be okay

What I Did

Paste the command(s) you ran and the output.
If there was a crash, please include the traceback here.

Sample Dockerfile to recreate

FROM python:3-alpine
RUN python --version
RUN pip install nipyapi

Building results in:

Collecting cffi>=1.7 (from cryptography>=1.3.4; extra == "security"->requests[security]->nipyapi) Downloading https://files.pythonhosted.org/packages/e7/a7/4cd50e57cc6f436f1cc3a7e8fa700ff9b8b4d471620629074913e3735fb2/cffi-1.11.5.tar.gz (438kB) Complete output from command python setup.py egg_info:

    No working compiler found, or bogus compiler options passed to
    the compiler from Python's standard "distutils" module.  See
    the error messages above.  Likely, the problem is not related
    to CFFI but generic to the setup.py of any Python package that
    tries to compile C code.  (Hints: on OS/X 10.8, for errors about
    -mno-fused-madd see http://stackoverflow.com/questions/22313407/
    Otherwise, see https://wiki.python.org/moin/CompLangPython or
    the IRC channel #python on irc.freenode.net.)

[Chaffelson]

Thanks for reporting this @apiri I'll do some research, from a bit of quick reading it looks like the dependencies for cryptography aren't being handled well.

Can you advise if this needs an urgent resolution to help you move forward , or is it more in the nature of 'this didn't work, and it would be convenient if it did'?

[apiri]

Definitely the latter. I was trying to overlay this into a Java based Alpine image and ran into this problem. My workaround was starting with a non-Alpine Python image and then "Java-izing" it. Just thought I might flag it so someone that actually knew what they were doing with Python might be able to do something meaningful 😄

[Chaffelson]

@apiri Investigated this, it's basically down to the dependencies building on the local os, and needing a bunch of stuff to do so - particularly the security features.

Adding the following to an alpine build will give you the supporting components you need, though I'd suggest you do a multistage build to avoid bloating:

RUN apk add -U --no-cache gcc build-base linux-headers ca-certificates python3-dev libffi-dev libressl-dev libxslt-dev

I've just tested this using python:3.6-alpine as a base.

Let me know if you want further progress on this so you can have NiPy as a Docker, and I could try to make you a staged build for it, but if you're fine with this answer then please close the issue.

[apiri]

Thanks for investigating. That works for me.

[Chaffelson]

Here's an example for future reference:

FROM python:3.7-alpine

LABEL maintainer="Dan Chaffelson <chaffelson@gmail.com>"
LABEL site="https://github.com/Chaffelson/nipyapi"

ENV BRANCH=cloudbreak
ENV PROFILE=/.secrets.yaml
ENV PYTHONUNBUFFERED=0

RUN apk update && apk upgrade \
    && apk add --no-cache --virtual .build-deps gcc build-base linux-headers \
    ca-certificates python3-dev libffi-dev libressl-dev git \
    && apk add -U --no-cache libxslt-dev bash \
    && git clone https://github.com/Chaffelson/nipyapi.git -b ${BRANCH} \
    && cd /nipyapi \
    && pip install -e . \
    && apk del .build-deps \
    && echo "python3 /nipyapi/nipyapi/demo/whoville.py $PROFILE" > /run-module.sh

ENTRYPOINT ["/bin/bash"]
CMD ["/run-module.sh"]

[kevdoran]

@Chaffelson is libxslt-dev a runtime requirement for nipyapi? I noticed it is installed separately from the ".build_deps" packages, was just curious if that is intentional.

[Chaffelson]

@kevdoran apologies I only just saw this question - my notes say it is required for template XML handling during runtime, thus it is kept in the build. The build-deps are only required while building the various libraries that are then used at runtime, if that makes sense.