How to use git + composer together
Results 1 to 8 of 8

Thread: How to use git + composer together

  1. #1
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,824

    How to use git + composer together

    Everybody is using composer these days -- including Rackspace. Their PHP SDK page instructs how to install the sdk into one's project using composer. I'm wondering mostly how to manage my git working directory when composer is being used. I've noticed some rough spots in working with a buddy.

    I created an empty dir to see what these install instructions would do to.
    Code:
    mkdir /tmp/foo
    cd /tmp/foo
    # insert composer install instructions here
    php composer.phar require rackspace/php-opencloud
    Using version ^1.16 for rackspace/php-opencloud
    ./composer.json has been created
    Loading composer repositories with package information
    Updating dependencies (including require-dev)
    Package operations: 5 installs, 0 updates, 0 removals
      - Installing mikemccabe/json-patch-php (0.1.0): Downloading (100%)         
      - Installing psr/log (1.0.2): Downloading (100%)         
      - Installing symfony/event-dispatcher (v2.8.18): Downloading (100%)         
      - Installing guzzle/guzzle (v3.9.3): Downloading (100%)         
      - Installing rackspace/php-opencloud (v1.16.0): Downloading (100%)         
    symfony/event-dispatcher suggests installing symfony/dependency-injection ()
    symfony/event-dispatcher suggests installing symfony/http-kernel ()
    guzzle/guzzle suggests installing guzzlehttp/guzzle (Guzzle 5 has moved to a new package name. The package you have installed, Guzzle 3, is deprecated.)
    Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.
    Writing lock file
    Generating autoload files
    Ignoring for a moment the deprecated package warning which has apparently been around for two years, and various conversations, I see that this operation has yielded a variety of files and folders:
    Code:
    composer.json
    composer.lock
    composer.phar
    vendor
    Now I've seen in many cases of .gitignore files that ignore the vendor folder (understandably so as one wouldn't want this bloatfest in one's repo) but I've never once seen composer.json, composer.lock, or composer.phar in the .gitignore file. I don't see composer.phar in any of these .gitignore files but it's my strong suspicion this file doesn't belong in the repo either as it has been auto-installed by the composer instructions.

    What about composer.json and composer.lock? Seems to me that, because these files change with every composer require command I run, that these files could be a hotspot in the repo as separate devs all run installs for various packages they want. Do they belong in the repo? Or do we commit composer.json and leave composer.lock out? The composer docs about the lock file say that it contains the 'exact versions' of whatever files were installed (presumably by the most recent require/install/update command).

    I'm guessing that composer.json and composer.lock should both go in the repo so the various devs stay in sync, but since the vendor file is .gitignored, Seems like we'll have to run php composer.phar update whenever the composer.json file gets changed by somebody.

    Can anyone outline a protocol for dealing with composer and git together?
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  2. #2
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    2,261
    You should ignore the vendor folder yes.

    composer.phar shouldn't even be in your working directory. move it to somewhere in your path, drop the .phar, and make it executable. Now you just type composer <command> no php and no .phar!

    composer.json is the file you manage, describing what you want to use. You should be editing this file with your package information as well as declaring what's a dev dependency vs an actual dependency (IE some HttpClient (per our other discussion) vs phpunit). You don't need to use composer require package to download a package. You can set up the composer.json file by hand specifying specific version requirements and then composer install or composer update to get them.

    composer.lock is a file that composer manages, you shouldn't ever edit this but it should be part of your repository. This will change as you install, remove or update packages. When you execute composer install later and have a lock file present, you will get the exact versions listed in the lock file. This means you dev and change libraries, but when you execute composer install on the server, you get exactly the same versions you tested with.

    composer update - this will update libraries to the newest versions with meet your requirements in the composer.json file (updates the lock file)
    composer require - this will install and require a new library to your project (updates the lock file)
    composer install - this will install the exact version in the lock file, if no lock file is present it will install the latest versions that satisfy the requirements of the composer.json file

    Integrating with git is basically as simple as executing a composer install after your branch changes. If you change to an older branch it may be beneficial to delete the vendor folder first to make sure it installs fresh each version.

    Edit: Oh I forgot to add, I never use the composer require command, I always edit the json file and then execute an install. This will resolve necessary version dependencies as well. Sometimes I will run composer update, but only if I plan on testing everything still works. However, composer assumes packages follow www.semver.org and so will avoid updating a library in an backwards incompatible manner.
    Last edited by Derokorian; 03-10-2017 at 10:40 PM.
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  3. #3
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    2,261
    Here to give you an idea, this is directly from my ansible script to install my website:
    Code:
    - name: checkout project
      git:
        repo: ssh://git@bitbucket.org/---/--.git
        dest: /source/derokorian.com
        version: ansible
        accept_hostkey: true
        force: true
        key_file: /root/.ssh/id_rsa
    
    - name: install composer dependencies
      command: composer install chdir=/source/derokorian.com
    The next steps, in order are - set up the application configuration files, then run migrations and now the app is ready to go!
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  4. #4
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,824
    Thank you for the helpful response!

    Quote Originally Posted by Derokorian View Post
    You should ignore the vendor folder yes.
    Done. Although this worries me. Given that packages seem to get updated all the time--and that all devs may not run composer update at the same time--I'm concerned about composer.lock on my machine being out of sync with the same file on my partner's machine, the dev machine, the production machine. I'll try to provide a scenario below.

    Quote Originally Posted by Derokorian View Post
    composer.phar shouldn't even be in your working directory. move it to somewhere in your path, drop the .phar, and make it executable. Now you just type composer <command> no php and no .phar!
    This assumes one wants composer globally installed, which I sometimes don't. The presence of the composer.phar file is a result of following the local install instructions on the Composer website. I think we can both agree that we don't want composer.phar in the repo. I'm going to leave composer.phar and add it to the .gitignore file.

    Quote Originally Posted by Derokorian View Post
    composer.json is the file you manage, describing what you want to use. You should be editing this file with your package information as well as declaring what's a dev dependency vs an actual dependency (IE some HttpClient (per our other discussion) vs phpunit). You don't need to use composer require package to download a package. You can set up the composer.json file by hand specifying specific version requirements and then composer install or composer update to get them.
    Not being fluent with composer.json and its nuances, I will probably follow the instructions given on the various projects I expect to use. Also, I am not myself developing any composer-compatible or composer-based project just yet. I just want to get this site updated from its awful Joomla beginnings and launched ASAP. That being the case, I'll be using composer-require.

    Quote Originally Posted by Derokorian View Post
    composer.lock is a file that composer manages, you shouldn't ever edit this but it should be part of your repository. This will change as you install, remove or update packages. When you execute composer install later and have a lock file present, you will get the exact versions listed in the lock file. This means you dev and change libraries, but when you execute composer install on the server, you get exactly the same versions you tested with.
    It seems potentially problematic to me to have composer.lock in the repo. A require, install, or update will update this file -- and one must run install/update any time one changes composer.json or pulls changes someone else has made from the repo. If you execute 'composer install/update' on the server, then doesn't this file get changed, possibly causing it to get out of sync with dev or my workstation?

    Quote Originally Posted by Derokorian View Post
    composer update - this will update libraries to the newest versions with meet your requirements in the composer.json file (updates the lock file)
    composer require - this will install and require a new library to your project (updates the lock file)
    composer install - this will install the exact version in the lock file, if no lock file is present it will install the latest versions that satisfy the requirements of the composer.json file
    require also downloads dependencies in my experience. Are you saying that install will not touch the composer.lock file if it already exists? If so, I'm starting to see a ray of light here.

    Quote Originally Posted by Derokorian View Post
    Integrating with git is basically as simple as executing a composer install after your branch changes. If you change to an older branch it may be beneficial to delete the vendor folder first to make sure it installs fresh each version.
    I think I'm starting to get it. DON'T run composer update when deploying to server, run composer install. This will leave the composer.lock file alone and just make sure to match the package versions listed in it. Thanks for the tip about switching branches.

    Quote Originally Posted by Derokorian View Post
    Edit: Oh I forgot to add, I never use the composer require command, I always edit the json file and then execute an install. This will resolve necessary version dependencies as well. Sometimes I will run composer update, but only if I plan on testing everything still works. However, composer assumes packages follow www.semver.org and so will avoid updating a library in an backwards incompatible manner.
    I'm not prepared to go editing composer.json files just yet. Is there any particular reason you avoid the require command?
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  5. #5
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,824
    Quote Originally Posted by Derokorian View Post
    Here to give you an idea, this is directly from my ansible script to install my website:
    Code:
    - name: checkout project
      git:
        repo: ssh://git@bitbucket.org/---/--.git
        dest: /source/derokorian.com
        version: ansible
        accept_hostkey: true
        force: true
        key_file: /root/.ssh/id_rsa
    
    - name: install composer dependencies
      command: composer install chdir=/source/derokorian.com
    The next steps, in order are - set up the application configuration files, then run migrations and now the app is ready to go!
    Thanks for this.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  6. #6
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    2,261
    I'm not gonna quote you, by the end it seemed like you got the idea.

    The basic jist is: never ever run composer update, always use composer install. update will change as many as every single library in the vendor folder. install will get you the exact version of a library that it was tested / developed with.

    The reason I don't like require, is other libraries might change by using require, where as updating the .json file and using install will avoid changing any libraries already listed in the lock file.
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  7. #7
    Senior Member Derokorian's Avatar
    Join Date
    Apr 2011
    Location
    Denver
    Posts
    2,261
    I lied, I'm quoting this

    Quote Originally Posted by sneakyimp View Post
    It seems potentially problematic to me to have composer.lock in the repo. A require, install, or update will update this file -- and one must run install/update any time one changes composer.json or pulls changes someone else has made from the repo. If you execute 'composer install/update' on the server, then doesn't this file get changed, possibly causing it to get out of sync with dev or my workstation?
    No it's not problematic - it's exactly the point. Install will NOT change the lock file, but install the exact versions listed in the lock file (down to the commit hash). Hence you should always be using install.

    The lock file is exactly how you keep different environments synchronized - because you get exactly the same version every time you install.
    Sadly, nobody codes for anyone on this forum. People taste your dishes and tell you what is missing, but they don't cook for you. ~anoopmail
    I'd rather be a comma, then a full stop.
    User Authentication in PHP with MySQLi - Don't forget to mark threads resolved - MySQL(i) warning

  8. #8
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,824
    The extra clarification is very helpful.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •