Asked  7 Months ago    Answers:  5   Viewed   29 times

Composer has the option to load several dependencies only while being in development, so the tools will not be installed in production (on the live server). This is (in theory) very handy for scripts that only make sense in development, like tests, fake-data-tools, debugger, etc.

The way to go is to add an additional require-dev block with the tools you need in dev:

"require-dev": {
    "codeception/codeception": ""

and then (theoretically) load these dependencies via

composer install --dev

Problem & Question:

Composer has changed the behaviour of install and update dramatically in 2013, require-dev-dependencies are now installed by default (!), feel free to create a composer.json with a require-dev block and perform an composer install to reproduce.

As the most accepted way to deploy is to push the composer.lock (that holds your current composer setup) and then do an composer install on the production server, this will also install the development stuff.

What's the correct way to deploy this without installing the -dev dependencies ?

Note: I'm trying to create a canonical Q/A here to clarify the weird Composer deployment. Feel free to edit this question.




There is IMHO a good reason why Composer will use the --dev flag by default (on install and update) nowadays. Composer is mostly run in scenario's where this is desired behavior:

The basic Composer workflow is as follows:

  • A new project is started: composer.phar install --dev, json and lock files are commited to VCS.
  • Other developers start working on the project: checkout of VCS and composer.phar install --dev.
  • A developer adds dependancies: composer.phar require <package>, add --dev if you want the package in the require-dev section (and commit).
  • Others go along: (checkout and) composer.phar install --dev.
  • A developer wants newer versions of dependencies: composer.phar update --dev <package> (and commit).
  • Others go along: (checkout and) composer.phar install --dev.
  • Project is deployed: composer.phar install --no-dev

As you can see the --dev flag is used (far) more than the --no-dev flag, especially when the number of developers working on the project grows.

Production deploy

What's the correct way to deploy this without installing the "dev" dependencies?

Well, the composer.json and composer.lock file should be committed to VCS. Don't omit composer.lock because it contains important information on package-versions that should be used.

When performing a production deploy, you can pass the --no-dev flag to Composer:

composer.phar install --no-dev

The composer.lock file might contain information about dev-packages. This doesn't matter. The --no-dev flag will make sure those dev-packages are not installed.

When I say "production deploy", I mean a deploy that's aimed at being used in production. I'm not arguing whether a composer.phar install should be done on a production server, or on a staging server where things can be reviewed. That is not the scope of this answer. I'm merely pointing out how to composer.phar install without installing "dev" dependencies.


The --optimize-autoloader flag might also be desirable on production (it generates a class-map which will speed up autoloading in your application):

composer.phar install --no-dev --optimize-autoloader

Or when automated deployment is done:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --optimize-autoloader

If your codebase supports it, you could swap out --optimize-autoloader for --classmap-authoritative. More info here

Wednesday, March 31, 2021
answered 7 Months ago

I would suggest you take a look at this:


By setting the COMPOSER env variable it is possible to set the filename of composer.json to something else.

For example:

COMPOSER=composer-other.json php composer.phar install

The generated lock file will use the same name: composer-other.lock in this example.

Wednesday, March 31, 2021
answered 7 Months ago

As stated in the question you already have both the versions of PHP on your system, As Laravel uses the cli version you need to enable 7.X and disable 5.X.

You can achieve that by below commands

$ sudo a2dismod php5.6 // disable the loaded version
$ sudo a2enmod php7.0 // enable the desired version
$ sudo service apache2 restart // restart apache to get it in action

For More information You can install different version of PHP using the below commands

For Apache

$ sudo apt install php5.6   [PHP 5.6]
$ sudo apt install php7.0   [PHP 7.0]
$ sudo apt install php7.1   [PHP 7.1]

For Ngix

$ sudo apt install php5.6-fpm   [PHP 5.6]
$ sudo apt install php7.0-fpm   [PHP 7.0]
$ sudo apt install php7.1-fpm   [PHP 7.1]

To install any PHP modules, simply specify the PHP version and use the auto-completion functionality to view all modules as follows.

------------ press Tab key for auto-completion ------------ 
$ sudo apt install php5.6 
$ sudo apt install php7.0 
$ sudo apt install php7.1 

Now you can install most required PHP modules as per your requirements.

------------ Install PHP Modules ------------
$ sudo apt install php5.6-cli php5.6-xml php5.6-mysql 
$ sudo apt install php7.0-cli php7.0-xml php7.0-mysql 
$ sudo apt install php7.1-cli php7.1-xml php7.1-mysql 
Wednesday, March 31, 2021
answered 7 Months ago

You also need to deploy the MINGW runtime dll (mingwm10.dll). This file is located in your Qt2009.5mingwbin directory.

Also pay attention to whether your application is compiled in debug mode or release mode. I just made the test with an hello world type application and Qt Creator. In the debug folders, I copied libgcc_s_dw2-1.dll, mingwm10.dll, QtCored4.dll and QtGuid4.dll and it works.

Pay attention to the d in dll names, which stands for debug: QtCore d 4.dll.

See Qt 4.6: Deploying an Application in Windows. For Qt 5, check this page.

Wednesday, September 8, 2021
answered 2 Months ago

If you know some python and have a lot of experience building web apps in other languages but don't totally understand where Heroku fits, I highly recommend Discover Flask, which patched a lot of the holes in my understanding of how these pieces all fit together.

Some of the things that I worked out:

  • you really do need an isolated virtual environment if you're going to deploy to Heroku, because Heroku installs Python modules from the requirements.txt file.

  • Gunicorn is a web server, and you definitely need to run your app under Gunicorn or it won't run on Heroku.

  • The "Procfile" doesn't just give the command you use to run the app locally. And Heroku requires it. So if you've got an app that was built to run on Heroku and it doesn't include a Procfile, they left something out.

  • You don't tell Heroku what your hostname is. When you run heroku create it should tell you what your domain name is going to be. And every time you run git push heroku master (or whatever branch you're pushing, maybe it isn't master), Heroku will (try to) restart your app.

  • Heroku doesn't support sqlite. You have to run your Production DB in Postgres.

This doesn't directly answer my question, but it does fill in some of the missing pieces that were making it hard for me to even ask the right question. RTFM notwithstanding. :)

Tuesday, October 5, 2021
Steven Frank
answered 3 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :