Bake composer in Docker images about s2i-php-container HOT 18 CLOSED

@bparees @mfojtik @jhadvig @soltysh @hhorak @praiskup WDYT?

from s2i-php-container.

Hmm, we cannot install composer in RHEL like we do in the assemble script, we'd need it to be packaged as RPM.

from s2i-php-container.

@rhcarvalho you tagged everybody except php maintainer :-) @remicollet is it reasonable to package composer for RHEL7? how fast it is being updated in upstream? will users be OK using fixed version of composer for couple months/year?

from s2i-php-container.

you tagged everybody except php maintainer :-)

Sorry for that, I just guessed by looking at the contributors list ;)

will users be OK using fixed version of composer for couple months/year?

Would be a separate thread maybe, but if the reasoning goes in this direction, then would it be a valid idea to install Python pip and virtualenv in the assemble script, as well as a similar approach to similar tools in other languages, so that users can get newer versions of those tools instead of what we have packaged? I thought that it was not something we'd consider doing.

from s2i-php-container.

@remicollet is it reasonable to package composer for RHEL7?

Composer is available in EPEL.
This doesn't seems reasonable to have it in RHEL, not stable, nearly no "official" release, only daily snapshot, which expire after 60 days

from s2i-php-container.

@bparees based on what @remicollet do you think it is reasonable we install EPEL version for RHEL7 image? I think that version will be behind centos7 version.

from s2i-php-container.

Indeed the latest release is 1.0.0-alpha11, from Nov 14, 2015.
Funny that 1.0.0-alpha1 is from Mar 1, 2012, so that's 3.5 years in alpha releases prior to 1.0, and still counting.

Perhaps it means php is granted to be the exception in terms of package management in our images 🍭

from s2i-php-container.

@rhcarvalho it would be hard to advocate packaging "alpha" release for RHEL7 :-)

from s2i-php-container.

@rhcarvalho
i'd be ok w/ doing this as long as we offer an env variable that the assemble script respects that allows users to request the latest composer be installed instead.

INSTALL_LATEST_COMPOSER or something.

and of course if we confirm that the epel packaged version doesn't have major bugs that break things on us.

from s2i-php-container.

I'm not following how you plan to make the composer from EPEL working with SCL variant of php -- having it re-packaged as SCL as well?

from s2i-php-container.

@hhorak composer package from EPEL works with SCL ;)

BTW, pulling package from EPEL doesn't seems acceptable.

from s2i-php-container.

@hhorak composer package from EPEL works with SCL ;)

Hm, interesting :)

BTW, pulling package from EPEL doesn't seems acceptable.

I agree, nothing from EPEL should be in official images.

from s2i-php-container.

BTW, pulling package from EPEL doesn't seems acceptable.

Which means we will have to ask Troy to package it. To me that seems a lot of effort. @rhcarvalho what is the reasoning to install composer in docker image? Speed? Consistency?

from s2i-php-container.

what is the reasoning to install composer in docker image?

Wait wait, can we slow down a bit? 🐌

First, I just wanted to run this idea by other people -- discuss, not saying we must do it. Decisions and priorities would only exist as outcomes of our discussion.

Second, I listed some of the reasons I could think of in the issue description, maybe we can reword those as "consistent and faster builds", but there's also the fact that other images install all of their "tools" in the builder image, not via assemble script, so there's also consistency among builder images at stake.

My understanding of the role of the assemble script is to, roughly, prepare the source code, install the dependencies and compile or some other step needed to get an image that can be "run".

Of course we could post-pone installing dependencies to the run script. If we did that, every time an image is run it would need to go download stuff from the internet, over and over again. Does that sound absurd and undesirable?

That sense of "absurd" is what I felt when I realized that every time we run a build we go fetch the latest version of composer.

From what I heard so far, perhaps that's not all that absurd, and perhaps PHP is granting itself some sort of special case because Composer is alpha, and we have an "impasse": we ideally want it coming from a stable packaged version, but none exist and might be hard or undesirable to make it exist.

Worth noting that I lack the point of view of a proficient PHP developer. As a PHP dev, shall I update Composer to the latest version every now and then? Is Composer my de facto tool for managing my projects' dependencies?

If it is the de facto tool and widely used, it justifies having it in the image (or as part of the default assemble script, if need be), something that will be leveraged by the dev community when they want to run their PHP projects in OpenShift.

from s2i-php-container.

@remicollet can you please answer @rhcarvalho questions? Personally, I don't see installing latest composer during assemble phase a big problem. My assumption is that composer API is not changing that much between versions (even it is an alpha). Also I assume PHP devs want always the latest composer available. If that is not the case, we can provide environment variable where devs can tweak the version of composer we install. Does that sound acceptable?

from s2i-php-container.

Using a nightly version seems, IMHO, a bad idea.

Probably we should switch to the latest "tagged" version (beta2 for now), but this will obviously change, so need to use the installer which will pull the right version.

People wanting the "latest" can always run "composer --self-update"

from s2i-php-container.

Forget previous, the assemble script already use the installer, which pull the last tagged version (excepted if --snapshot is used, in the future will pull the "stable" version, excepted if --preview is used)

from s2i-php-container.

Ok, so I get that PHP/composer grants itself an exceptional status, and we keep installing it in the assemble script, not in the Dockerfile like we do for other images/tools. Closing.

from s2i-php-container.