Include support for php's Composer dependency manager

We go just one step further :

1. chmod +x composer.phar
2. mkdir ~/composer-bin
3. mv composer.phar ~/composer-bin
4. echo "export PATH=~/composer-bin:$PATH" >> ~/.bashrc

Then log out and log in again and composer is then available anywhere in the user account

I am not all that familiar with command line, but I am taking it as permission change, make new directory, move composer to new directory, and then not quite sure what the last step actually does. I've been wanting to use composer for years, but never did being on cpanel and worried about compatibility problems whether from the get go or once the nightly cpanel update happens. Would like to give this a shot tonight to see what happens.

Yes, you are right about the first 3 steps, the final one just adds a line to the user's ~/.bashrc file, this line tells bash to look in the ~/composer-bin directory for executables allowing you to run the "composer" command from any folder.

Here is the complete procedure using the one recommended one composer's site (that runs a md5 and changes the file permissions for you :

https://getcomposer.org/download/

Edit 1 : I've removed a few lines thanks to composer-setup.php options

Edit : 2 : You will need to check the link above for the SHA384 line (line 3) as it will change with every new version of composer.

1. mkdir ~/composer-bin
2. php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
3. php -r "if (hash_file('SHA384', 'composer-setup.php') === '92102166af5abdb03f49ce52a40591073a7b859a86e8ff13338cf7db58a19f7844fbc0bb79b2773bf30791e935dbd938') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
4. php composer-setup.php --install-dir=~/composer-bin --filename=composer
5. php -r "unlink('composer-setup.php');
6. echo "export PATH=~/composer-bin:$PATH" >> ~/.bashrc

Log out

Log in again

Then run :

composer --version

This should output someting like this :

1. composer --version

   Composer version 1.2-dev (a4e8d858ba71995f74622c090c9a523e1d1297ed) 2016-05-16 17:50:37

   
   

Thanks - really appreciate it!

ok, well line 4 doesn't work so :

First et current hash code from : https://getcomposer.org/download/

Then :

1. mkdir ~/composer-bin
2. cd ~/composer-bin
3. php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
4. php -r "if (hash_file('SHA384', 'composer-setup.php') === 'REPLACE_THIS_WITH_CURRENT_SHA384_HASH_FROM_LINK_ABOVE') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
5. php composer-setup.php --filename=composer
6. php -r "unlink('composer-setup.php');
7. echo "export PATH=~/composer-bin:$PATH" >> ~/.bashrc
8. source ~/.bashrc

PHP doesn't like the ~/ in the folder path so I added a cd command, and so you don't have to log out and in again I added the last line.

Having cPanel implement this feature does not mean it won't be available through command line.

The idea behind having cPanel implement this feature with an interface is to allow people to use composer without having to give everybody shell access.

Providing SSH access isn't more dangerous than providing perl/cgi or php.

The echo line should have single quotes otherwise the $PATH variable is replaced :

1. echo 'export PATH=~/composer-bin:$PATH' >> ~/.bashrc

I think both. Composer replaces PEAR (among other things), so it makes sense for WHM (or even cPanel) to have a UI for Composer like it does for PEAR. However, under the hood it would be the same composer, and there's no reason not to enable users to manipulate it from the shell as well.

We're not the most attached to this feature request as we believe SSH access is required to use this composer properly and that other shell commands (for example artisan with laravel) are often also required and that a documentation how to install composer via SSH should suffice.

We vote for cPanel just installing Composer if the user requests it in their cPanel control panel. I presume there are some scripts that require composer without actally requiring SSH access to run it.

I see making a web interface for running Composer commands as being complicated to do right and I'm not sure how many developpers would be pleased to have to run composer from inside cPanel.

Both would be good, Tom.

I don't see what's complicated about running it through cPanel interface

It should be as easy as integrating this into the filemanager itself once you select a file named composer.json it will activate a menu with composer options A dropdown with

Composer Install

Composer Update

Would be enough; Editing the composer.json file should be up to the developer, I would have done this through a PHP script but you cannot guarantee it won't timeout while installing packages while running this through cPanel Interface it's guaranteed to not timeout (Something similar to install perl module in WHM process).

To sum up everything:

1- Composer is installed server wide & kept up to date through cPanel post-update scripts.

2- Integration through filemanager when clicking on a composer.json file is enough.

3- People who prefer to use composer through SSH can still do so as the executable can be run from any account just like any other linux command.

Sounds good to me :)

How you you manage composer asking questions ? For example sometimes you have to enter github authentification if your IP has made too many requests to github (happens all the time on servers with multiple dev's using github via composer).

Tom, I would focus on ensuring the command line tool is installed. I recognize that it can be installed as a phar by a limited permission user, but each extra step adds friction. There was a time when php developers asked their clients to be hosted on cPanel so they could get the best environment around. If you want to get back to that point, providing the basic tools for the job is an important step.

We've finally installed it globaly. We run a daily composer self-update with in the /scripts/postupcp file on a normal cPanel account (using su to run the command in that user's cage) and then simply copy the resulting composer file accross if it has changed to /usr/local/bin/composer.

This is very easy to setup for a sysadmin, and by not running composer as root makes it as secure as it would be if installed directly on a user's account.

Because of this, we no longer require composer being installed on a user's account (installing it globaly is fine).

In our point of view the question is, will beginner users who want to use composer end up learning how to run commands on SSH ?

We've had more and more customers asking about how to connect to SSH, which means that more and more developers are using command line.

Windows should soon include bash which will make using SSH for them easier too.

Instead of user's running these commands from within cPanel we will be writing easy documentation to explain how to connect to SSH and run these commands.

For the authorization part it's just a config file like any other config, it can be created manually or cPanel could add a third option to the menu to paste the token.

I don't think you would face authorization issue on a production server, As you would rarely pull packages plus with composer caching a package might be already downloaded by another user so you won't have to fetch it from github at all.