include pipenv at build of s2i container image rather than downloading it during use of s2i

[goern]

As a S2I user, I want use python 3.6 with Pipenv, so that pipenv has a specific version installed during build of the s2i builder image and is not pulled down from the internet during usage of the s2i builder image.

[touchardv]

Related to this issue, it is not possible to use pipenv in a closed environment (no direct access to the Internet) as it can not be installed properly (it seems the --isolated argument makes pip ignore PIP_INDEX_URL that could be used to go via an internal mirror).

Therefore, yes, it would be great to have a default pipenv installed in the image.

[goern]

@hhorak ping

[omron93]

@torsava ???

[torsava]

The problem is, pipenv is not packaged in any version of CentOS right now, only Fedora. We could theoretically pip install it during the build of the image, but then we're distributing an untested version right in the image (plus it's unpackaged dependencies). I'm leaning towards not proceeding with this for the time being. Let's fix the PIP_INDEX_URL for the closed environment so that can be used as an alternative.

[omron93]

theoretically pip install it during the build of the image, but then we're distributing an untested version right in the image (plus it's unpackaged dependencies)

I thing this wouldn't be even possible in internal build system (used by Fedora/RHEL images). Only rpms can be installed during the build. (or some dirty hack is needed to be able to access Internet)

[goern]

pipenv is not packaged in any version of CentOS right now, only Fedora

@torsava so I understand that using CentOS is a hard requirement?

but then we're distributing an untested version right in the image (plus it's unpackaged dependencies).

which is even better than downloading a (potentially completely broken) version from the internet during build of an application via s2i

@CermakM

[torsava]

theoretically pip install it during the build of the image, but then we're distributing an untested version right in the image (plus it's unpackaged dependencies)

I thing this wouldn't be even possible in internal build system (used by Fedora/RHEL images). Only rpms can be installed during the build. (or some dirty hack is needed to be able to access Internet)

Ah, indeed. Thus I don't consider this feasible.

[torsava]

pipenv is not packaged in any version of CentOS right now, only Fedora

@torsava so I understand that using CentOS is a hard requirement?

We want to keep the Fedora/CentOS versions functionally as similar as possible.

but then we're distributing an untested version right in the image (plus it's unpackaged dependencies).

which is even better than downloading a (potentially completely broken) version from the internet during build of an application via s2i

In that case one is already downloading other packages using pipenv, so adding pipenv itself is not a large departure from that.

[frenzymadness]

This is related to issue #290 . If the functionality proposed in issue #290 would be implemented, you'd be able to specify a specific version of pipenv to use so you'd be able to choose the version you want.

What do you think about this partial solution?

[frenzymadness]

Implementation of the PIN_PIPENV_VERSION is in #387

[frenzymadness]

PIN_PIPENV_VERSION is available.