New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal/question] install composer by default #177

Closed
schmunk42 opened this Issue Jan 11, 2016 · 34 comments

Comments

Projects
None yet
@schmunk42

schmunk42 commented Jan 11, 2016

I'd like to propose or discuss to install composer from https://getcomposer.org by default.

I know that this requires additional extensions installed by default (see also #17). And that it's not a 100% minimal solution, but it would greatly simplify dockerized testing of PHP projects, like described here: docker-php/docker-php#144.

An alternative would be to setup a new automated-build repository which does the job, but I'd say that composer is used by almost all PHP projects nowadays.

Working examples for package managers from other Docker images:

docker run ruby gem
docker run nodejs npm
docker run python pip
@hairmare

This comment has been minimized.

Show comment
Hide comment
@hairmare

hairmare Jan 11, 2016

👍 this as it make life way easier for folks that did not grow up on php.

FWIW the (non-php) package managers you mention all get bundled with their upstream languages, whereas composer does not get this treatment by PHP/Zend.

The lack of regular releases from composer makes this harder than it should be.

If you're just after a php:5.6-cli based composer, there are some automated dockerhub images at https://github.com/RobLoach/docker-composer that might fit the bill.

hairmare commented Jan 11, 2016

👍 this as it make life way easier for folks that did not grow up on php.

FWIW the (non-php) package managers you mention all get bundled with their upstream languages, whereas composer does not get this treatment by PHP/Zend.

The lack of regular releases from composer makes this harder than it should be.

If you're just after a php:5.6-cli based composer, there are some automated dockerhub images at https://github.com/RobLoach/docker-composer that might fit the bill.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Jan 11, 2016

I saw the images you mentioned, but they are only built for 5.6 and I think handling releases could be made simpler.

We could install the latest release of composer with

curl -sS https://getcomposer.org/installer | php -- --version=$(curl -s https://api.github.com/repos/composer/composer/releases/latest | grep -oP '"tag_name": "\K[^"]+')

Related:

schmunk42 commented Jan 11, 2016

I saw the images you mentioned, but they are only built for 5.6 and I think handling releases could be made simpler.

We could install the latest release of composer with

curl -sS https://getcomposer.org/installer | php -- --version=$(curl -s https://api.github.com/repos/composer/composer/releases/latest | grep -oP '"tag_name": "\K[^"]+')

Related:

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Jan 14, 2016

Contributor

it would probably be useful to install git and the zip extension at the same time

Contributor

mathroc commented Jan 14, 2016

it would probably be useful to install git and the zip extension at the same time

@yosifkit

This comment has been minimized.

Show comment
Hide comment
@yosifkit

yosifkit Jan 25, 2016

Member

The part that makes me hesitant is that composer isn't maintained or recommended by upstream and we try to stay as close to their recommendations as possible (unless someone can point me to such a recommendation).

Member

yosifkit commented Jan 25, 2016

The part that makes me hesitant is that composer isn't maintained or recommended by upstream and we try to stay as close to their recommendations as possible (unless someone can point me to such a recommendation).

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jan 25, 2016

Composer maintainer here. I fully hear you on the frequent releases issue, and I'm working hard lately to reach a 1.0 stable which would already be easier to manage for distributions.

Do note that some distros already provide composer packages though, debian testing has it https://packages.debian.org/stretch/composer and rpms are available via http://rpms.famillecollet.com/rpmphp/zoom.php?rpm=composer who is maintaining php for redhat AFAIK, so relatively official.

Seldaek commented Jan 25, 2016

Composer maintainer here. I fully hear you on the frequent releases issue, and I'm working hard lately to reach a 1.0 stable which would already be easier to manage for distributions.

Do note that some distros already provide composer packages though, debian testing has it https://packages.debian.org/stretch/composer and rpms are available via http://rpms.famillecollet.com/rpmphp/zoom.php?rpm=composer who is maintaining php for redhat AFAIK, so relatively official.

@drpain

This comment has been minimized.

Show comment
Hide comment
@drpain

drpain Mar 5, 2016

👍 Yes please!

The majority of frameworks now use composer for installs, kindoff making this a requirement. That is unless you are building something the hard way, and writing every nut and bolt yourself.

drpain commented Mar 5, 2016

👍 Yes please!

The majority of frameworks now use composer for installs, kindoff making this a requirement. That is unless you are building something the hard way, and writing every nut and bolt yourself.

@urzds

This comment has been minimized.

Show comment
Hide comment
@urzds

urzds Apr 14, 2016

Related to #100?

urzds commented Apr 14, 2016

Related to #100?

@xabbuh

This comment has been minimized.

Show comment
Hide comment
@xabbuh

xabbuh Apr 14, 2016

By the way, Composer did get its first stable release in the meantime.

xabbuh commented Apr 14, 2016

By the way, Composer did get its first stable release in the meantime.

mathroc added a commit to mathroc/php that referenced this issue Jul 14, 2016

@mathroc mathroc referenced this issue Jul 14, 2016

Closed

Add a docker-php-composer-install script #260

6 of 6 tasks complete
@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Jul 14, 2016

Contributor

what do you think about adding a docker-php-composer-install script ? ( see #260 )

Contributor

mathroc commented Jul 14, 2016

what do you think about adding a docker-php-composer-install script ? ( see #260 )

@sylus

This comment has been minimized.

Show comment
Hide comment
@sylus

sylus Jul 14, 2016

We already have a base composer docker image @ https://github.com/RobLoach/docker-composer that is based on the php image and is working its way to become official image.

Isn't this duplicating this work?

sylus commented Jul 14, 2016

We already have a base composer docker image @ https://github.com/RobLoach/docker-composer that is based on the php image and is working its way to become official image.

Isn't this duplicating this work?

@yosifkit

This comment has been minimized.

Show comment
Hide comment
@yosifkit

yosifkit Jul 14, 2016

Member

@sylus, it looks like there is a bit more to those images than just installing composer. They are also all based on the cli variant so there is no apache or fpm.

Member

yosifkit commented Jul 14, 2016

@sylus, it looks like there is a bit more to those images than just installing composer. They are also all based on the cli variant so there is no apache or fpm.

@sylus

This comment has been minimized.

Show comment
Hide comment
@sylus

sylus Jul 14, 2016

Just adding @RobLoach if has any comments. I think the additional dependencies are to fulfill potential requirements of composer? Didn't think about the apache or fpm variants, thx ^_^

sylus commented Jul 14, 2016

Just adding @RobLoach if has any comments. I think the additional dependencies are to fulfill potential requirements of composer? Didn't think about the apache or fpm variants, thx ^_^

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Jul 18, 2016

Contributor

https://github.com/RobLoach/docker-composer is indeed useful but I think a simple way to have composer right into library/php is best. the PR I made provides an easy way to have a basic composer installed and needed package & deps can be added as required (eg: git, ext-zip, etc.) It makes it easy to build a light image with composer installed.

It can also be used to install composer just for build time:

FROM php

RUN docker-php-composer install && composer install --no-dev && rm $(which composer)
Contributor

mathroc commented Jul 18, 2016

https://github.com/RobLoach/docker-composer is indeed useful but I think a simple way to have composer right into library/php is best. the PR I made provides an easy way to have a basic composer installed and needed package & deps can be added as required (eg: git, ext-zip, etc.) It makes it easy to build a light image with composer installed.

It can also be used to install composer just for build time:

FROM php

RUN docker-php-composer install && composer install --no-dev && rm $(which composer)
@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Jul 18, 2016

One thing which would be also nice, is a possibility to set an GitHub API token by an ENV variable, like so:

(* both not perfect solutions IMHO, but composer is not really usable without GitHub tokens)

schmunk42 commented Jul 18, 2016

One thing which would be also nice, is a possibility to set an GitHub API token by an ENV variable, like so:

(* both not perfect solutions IMHO, but composer is not really usable without GitHub tokens)

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Jul 18, 2016

Contributor

@schmunk42 I'm usually mounting a volume on ~/.composer/ to deal with this, it lets composer save its token (and cache!) in a persistent location
to work with a ENV variable we would have to either add an entrypoint wrapper to the image or a wrapper to composer. I'm not sure what's the best here

Contributor

mathroc commented Jul 18, 2016

@schmunk42 I'm usually mounting a volume on ~/.composer/ to deal with this, it lets composer save its token (and cache!) in a persistent location
to work with a ENV variable we would have to either add an entrypoint wrapper to the image or a wrapper to composer. I'm not sure what's the best here

@RobLoach

This comment has been minimized.

Show comment
Hide comment
@RobLoach

RobLoach Jul 18, 2016

Would be great to have Composer be available directly in the PHP container. It has become the defacto method for installing PHP dependencies.

it looks like there is a bit more to those images than just installing composer

Correct, and these additions probably don't need to be brought into the PHP container. Even just bringing it in as /usr/bin/composer or similar would be a great benefit.

RobLoach commented Jul 18, 2016

Would be great to have Composer be available directly in the PHP container. It has become the defacto method for installing PHP dependencies.

it looks like there is a bit more to those images than just installing composer

Correct, and these additions probably don't need to be brought into the PHP container. Even just bringing it in as /usr/bin/composer or similar would be a great benefit.

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Jul 18, 2016

Contributor

running docker-php-composer-install brings the image from 59.55 MB to 61.19 MB. I guess that's small enough. I can add it into #260 if everyone feels the same (and the script can still be used to customize the composer installation)

Contributor

mathroc commented Jul 18, 2016

running docker-php-composer-install brings the image from 59.55 MB to 61.19 MB. I guess that's small enough. I can add it into #260 if everyone feels the same (and the script can still be used to customize the composer installation)

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Sep 3, 2016

Contributor

fwiw, there a recent discussion in php internals about an rfc to Deprecate PEAR/PECL & Replace with composer/pickle
it's not yet (and maybe won't be) an official recommendation but maybe that and the stable releases of composer will be enough to consider moving this forward ?

Contributor

mathroc commented Sep 3, 2016

fwiw, there a recent discussion in php internals about an rfc to Deprecate PEAR/PECL & Replace with composer/pickle
it's not yet (and maybe won't be) an official recommendation but maybe that and the stable releases of composer will be enough to consider moving this forward ?

@sandrokeil

This comment has been minimized.

Show comment
Hide comment
@sandrokeil

sandrokeil Sep 4, 2016

It's not a good idea to install Composer, because Composer has additional system deps and it exists already an official Composer Docker image.

sandrokeil commented Sep 4, 2016

It's not a good idea to install Composer, because Composer has additional system deps and it exists already an official Composer Docker image.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Sep 4, 2016

@sandrokeil Is this really an official image from composer? I couldn't find anything about it in the docs.

schmunk42 commented Sep 4, 2016

@sandrokeil Is this really an official image from composer? I couldn't find anything about it in the docs.

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Sep 4, 2016

Contributor

it's not an official image (but it's the most popular) and as said before, it bundles more than just composer.
another point for having composer in the same image than php: packages can add extensions in there dependencies if the extensions installed in your php image and composer image aren't the same you might have unexpected errors and/or have to install extensions in both images

Contributor

mathroc commented Sep 4, 2016

it's not an official image (but it's the most popular) and as said before, it bundles more than just composer.
another point for having composer in the same image than php: packages can add extensions in there dependencies if the extensions installed in your php image and composer image aren't the same you might have unexpected errors and/or have to install extensions in both images

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Sep 4, 2016

Contributor

a reminder: the PR #260 does not install composer by default (don't know if it should), at the moment it provides a scripts to add composer inside the image similarly to how extensions are added

Contributor

mathroc commented Sep 4, 2016

a reminder: the PR #260 does not install composer by default (don't know if it should), at the moment it provides a scripts to add composer inside the image similarly to how extensions are added

@sandrokeil

This comment has been minimized.

Show comment
Hide comment
@sandrokeil

sandrokeil Sep 5, 2016

I'm not sure if it's worth it. Maybe for testing or development. Normally you would create an own base PHP Docker image for your application, where other PHP Docker images like Composer depends on (like in my example above).

You need git and bz2 for Composer to work properly and this should not be in the PHP image, if only needed for Composer.

sandrokeil commented Sep 5, 2016

I'm not sure if it's worth it. Maybe for testing or development. Normally you would create an own base PHP Docker image for your application, where other PHP Docker images like Composer depends on (like in my example above).

You need git and bz2 for Composer to work properly and this should not be in the PHP image, if only needed for Composer.

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Sep 6, 2016

Contributor

@sandrokeil I'm not sure what you mean

I do have separate image for php-fpm and composer in development in some projects, in some other I don't (docker-composer exec php composer works well too)
What makes it "normal", one of the popular image for a language I know (nodejs) and the main other I'm using (schickling/rust) also includes their package manager
@schmunk42 also mention that ruby and python are doing the same

anyway, I don't get why it would be a problem to either have a script to install it easily (or even install it by default)

You need git and bz2 for Composer to work properly and this should not be in the PHP image, if only needed for Composer.

composer is certainly more useful with git and bz2, but they don't need to be installed by default (in #260 even composer is not installed by default). tbh I don't get why it would be a problem to install them in a php image.
If you care about the image size and/or security issues it might bring, you can remove them just after using composer in your production images, eg:

FROM php:7.0-alpine

ADD src/ /app/

RUN apk add --no-cache --virtual .composer-deps git bz2 && \
    docker-php-composer-install && \
    cd /app/ && composer install --optimize-autoloader--no-dev && \
    apk del .composer-deps && \
    rm $(which composer)
Contributor

mathroc commented Sep 6, 2016

@sandrokeil I'm not sure what you mean

I do have separate image for php-fpm and composer in development in some projects, in some other I don't (docker-composer exec php composer works well too)
What makes it "normal", one of the popular image for a language I know (nodejs) and the main other I'm using (schickling/rust) also includes their package manager
@schmunk42 also mention that ruby and python are doing the same

anyway, I don't get why it would be a problem to either have a script to install it easily (or even install it by default)

You need git and bz2 for Composer to work properly and this should not be in the PHP image, if only needed for Composer.

composer is certainly more useful with git and bz2, but they don't need to be installed by default (in #260 even composer is not installed by default). tbh I don't get why it would be a problem to install them in a php image.
If you care about the image size and/or security issues it might bring, you can remove them just after using composer in your production images, eg:

FROM php:7.0-alpine

ADD src/ /app/

RUN apk add --no-cache --virtual .composer-deps git bz2 && \
    docker-php-composer-install && \
    cd /app/ && composer install --optimize-autoloader--no-dev && \
    apk del .composer-deps && \
    rm $(which composer)
@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Sep 6, 2016

For me, one of the most important things is, that I can docker build my whole application - that's what Docker is about.
With a separate container/image, I need volumes_from or on the host, which makes things much more error prone.

schmunk42 commented Sep 6, 2016

For me, one of the most important things is, that I can docker build my whole application - that's what Docker is about.
With a separate container/image, I need volumes_from or on the host, which makes things much more error prone.

@alcohol

This comment has been minimized.

Show comment
Hide comment
@alcohol

alcohol Oct 25, 2016

I would prefer to see Composer as part of the base image. I started on composer/docker, but it just seems excessive for a simple binary file.

Also, the fact that most people need a lot of extensions and what not for their plugins/etc, which they also require for their application container (which is usually derived from one of the official php images), it just makes it more convenient. No need to mess with volumes etc.

alcohol commented Oct 25, 2016

I would prefer to see Composer as part of the base image. I started on composer/docker, but it just seems excessive for a simple binary file.

Also, the fact that most people need a lot of extensions and what not for their plugins/etc, which they also require for their application container (which is usually derived from one of the official php images), it just makes it more convenient. No need to mess with volumes etc.

@bweston92

This comment has been minimized.

Show comment
Hide comment
@bweston92

bweston92 Oct 25, 2016

That means people who don't want or need composer in there have to have it?

@schmunk42 Would you really want to build a production image with Composer inside, after building it is never going to be used again?

I agree with @sandrokeil just use your own base image and keep php vanilla.

bweston92 commented Oct 25, 2016

That means people who don't want or need composer in there have to have it?

@schmunk42 Would you really want to build a production image with Composer inside, after building it is never going to be used again?

I agree with @sandrokeil just use your own base image and keep php vanilla.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Oct 25, 2016

@schmunk42 Would you really want to build a production image with Composer inside, after building it is never going to be used again?

We use composer inside the Dockerfile to build the image, copying vendor from the host is too error-prone IMO.

schmunk42 commented Oct 25, 2016

@schmunk42 Would you really want to build a production image with Composer inside, after building it is never going to be used again?

We use composer inside the Dockerfile to build the image, copying vendor from the host is too error-prone IMO.

@alcohol

This comment has been minimized.

Show comment
Hide comment
@alcohol

alcohol Oct 25, 2016

We use composer inside the Dockerfile to build the image, copying vendor from the host is too error-prone IMO.

Yeah, but their argument (which is valid) is that you can install composer before doing so, and then remove it after that step, all in the same Dockerfile, thus leaving no trace of its presence in the final image.

alcohol commented Oct 25, 2016

We use composer inside the Dockerfile to build the image, copying vendor from the host is too error-prone IMO.

Yeah, but their argument (which is valid) is that you can install composer before doing so, and then remove it after that step, all in the same Dockerfile, thus leaving no trace of its presence in the final image.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Oct 25, 2016

thus leaving no trace of its presence in the final image.

Not to be picky here, but that's not correct (unless I've missed something ;)). docker history will show you all CMDs etc... ran in the build process. You should be able to create a container from a specific layer and you don't reduce your image size, when removing it in a separate setup. (Although, you could install composer and your app in one RUN and remove composer afterwards, but that seems a bit overoptimized to me.)

We also use composer i.e. to run composer show in the image for debugging, and I'd also like to use composer from the image as the standard way for installing/copying vendor files locally, if we would not suffer from docker/for-mac#77

schmunk42 commented Oct 25, 2016

thus leaving no trace of its presence in the final image.

Not to be picky here, but that's not correct (unless I've missed something ;)). docker history will show you all CMDs etc... ran in the build process. You should be able to create a container from a specific layer and you don't reduce your image size, when removing it in a separate setup. (Although, you could install composer and your app in one RUN and remove composer afterwards, but that seems a bit overoptimized to me.)

We also use composer i.e. to run composer show in the image for debugging, and I'd also like to use composer from the image as the standard way for installing/copying vendor files locally, if we would not suffer from docker/for-mac#77

@bweston92

This comment has been minimized.

Show comment
Hide comment
@bweston92

bweston92 Oct 25, 2016

@schmunk42 but not everyone needs composer especially in production.

In fact our CI runs composer info -i as a build step so we know what is inside that container.

We are just forwarding the application code with the artefacts gathered using composer and create an image using just the files. I just don't see why force composer in a base image.

bweston92 commented Oct 25, 2016

@schmunk42 but not everyone needs composer especially in production.

In fact our CI runs composer info -i as a build step so we know what is inside that container.

We are just forwarding the application code with the artefacts gathered using composer and create an image using just the files. I just don't see why force composer in a base image.

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Oct 25, 2016

Contributor

That means people who don't want or need composer in there have to have it?
I agree with @sandrokeil just use your own base image and keep php vanilla.

@bweston92 in my proposal (see #260) composer is not installed by default, it only add a script to install it as easily as a php extension and a few tweaks (an additional env var and updated $PATH) to make working with it nicer

Contributor

mathroc commented Oct 25, 2016

That means people who don't want or need composer in there have to have it?
I agree with @sandrokeil just use your own base image and keep php vanilla.

@bweston92 in my proposal (see #260) composer is not installed by default, it only add a script to install it as easily as a php extension and a few tweaks (an additional env var and updated $PATH) to make working with it nicer

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Oct 25, 2016

I just don't see why force composer in a base image.

I'd be absolutely fine with a php-composer-install script, like php-ext-install

Another important thing would be correct API token handling.

schmunk42 commented Oct 25, 2016

I just don't see why force composer in a base image.

I'd be absolutely fine with a php-composer-install script, like php-ext-install

Another important thing would be correct API token handling.

@tianon tianon referenced this issue Nov 2, 2016

Merged

add composer #2290

9 of 9 tasks complete
@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Dec 5, 2016

Contributor

for those interested, here is a follow up on this issue being closed and _/composer added to hub.docker.com : #344

Contributor

mathroc commented Dec 5, 2016

for those interested, here is a follow up on this issue being closed and _/composer added to hub.docker.com : #344

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment