Description of problem: Trying to create a python app using sti build but library is missing. Version-Release number of selected component (if applicable): 2.7 and 3.5 How reproducible: always Steps to Reproduce: 1. oc new-app python:2.7~https://github.com/sopel-irc/sopel.git 2. oc new-app python:3.5~https://github.com/sopel-irc/sopel.git 3. oc new-app python:latest~https://github.com/sopel-irc/sopel.git 4. oc logs -f bc/sopel Actual results: Sti build fails like: > ---> Installing dependencies ... > You are using pip version 7.1.0, however version 9.0.1 is available. > You should consider upgrading via the 'pip install --upgrade pip' command. > Collecting xmltodict (from -r requirements.txt (line 1)) > Downloading xmltodict-0.11.0-py2.py3-none-any.whl > Collecting pytz (from -r requirements.txt (line 2)) > Downloading pytz-2017.2-py2.py3-none-any.whl (484kB) > Collecting praw (from -r requirements.txt (line 3)) > Downloading praw-5.0.1-py2.py3-none-any.whl (86kB) > Collecting pyenchant (from -r requirements.txt (line 4)) > Downloading pyenchant-1.6.8.tar.gz (63kB) > Complete output from command python setup.py egg_info: > Traceback (most recent call last): > File "<string>", line 20, in <module> > File "/tmp/pip-build-qSAnGK/pyenchant/setup.py", line 210, in <module> > import enchant > File "enchant/__init__.py", line 92, in <module> > from enchant import _enchant as _e > File "enchant/_enchant.py", line 145, in <module> > raise ImportError(msg) > ImportError: The 'enchant' C library was not found. Please install it via your > OS package manager, or use a pre-built binary wheel from PyPI. > ---------------------------------------- > Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-qSAnGK/pyenchant Expected results: build succeeds Additional info: I think there should be some mechanism to add additional packages for the builds, otherwise running python apps would be hit or miss.
The only thing needed to add to Dockerfile so that `sopel` build can work is the `enchant` RPM.
(In reply to Aleksandar Kostadinov from comment #0) > Additional info: > I think there should be some mechanism to add additional packages for the > builds, otherwise running python apps would be hit or miss. IMHO that is the right way. Otherwise we will end up with enormously big image which works only when we guessed right what is being used. Images should be as small as possible, right?
Shouldn't there be a sti mechanism to add additional packages when needed? Would be hard for users to keep the sti image uptodate with security and other updates. It makes sense IMO to have the whole workflow automated. Otherwise users would stay outdated.
(In reply to Aleksandar Kostadinov from comment #4) > Shouldn't there be a sti mechanism to add additional packages when needed? > > Would be hard for users to keep the sti image uptodate with security and > other updates. It makes sense IMO to have the whole workflow automated. > Otherwise users would stay outdated. There is an s2i mechanism to add additional Python packages through requirements.txt and similar. However, installing additional RPMs is a more complex issue and not currently covered by s2i to my knowledge. You can file a bug against s2i requesting that feature to be added.
Though it may be deemed that installing arbitrary RPMs is a feature outside the scope of s2i, in that case you might want to extend the image yourself instead.
I tried to explain earlier, that in online/dedicated one cannot have automatic builds with the docker strategy. Thus making the support of a sti builder image a manual process (or a process in an external infrastructure) which IMO misses the point of using OpenShift. If this sti builder management is not done right then user can be exposed to vulnerabilities if that sti builder image becomes outdated. I'm ok if this bug is moved to the base sti component. But I can't see exactly which product/component should I choose.
There is a source-to-image component under both RHSCLs and Fedora products, so assigning to RHSCLs, please reassign if appropriate.
Please file RFEs upstream, we are just downstream packaging here, it doesn't make sense to track RFEs here. https://github.com/openshift/source-to-image/issues
FYI https://github.com/openshift/source-to-image/issues/786