Composer lock and json

[purplefish32]

@stefk

• composer.lock and composer.json should not be ignored.
• composer.json.dist should not be included in the repo.
• the readme and travis files should be updated to reflect the changes

The composer.lock guarantees that via a "composer install" the user will install the exact commits that the devs have intended and not the "bleeding edge" versions that may be broken. The only other way is to have exact commits or tags in the composer.json file.

A normal user should just have to download and do a "composer install".

The method that seems logic would be for the devs to do a "composer update" and test just before tagging a new version of claroline.

[maxailloud]

I agree for the composer.lock file but not for composer.json. composer.json is not a file that has its place on a VCS. Its a convention that allow you to switch version of package for testing purpose, and when it's good you can update the .dist one.

By the way a normal user dont do a composer install, he launches a script that do it. If he won't be able to copy/paste the composer.json.dist file he won't be able to launch composer.

[purplefish32]

composer.json also has its place in a VCS, take a look at any popular piece of software that uses composer :

• https://github.com/symfony/symfony/blob/master/composer.json
• https://github.com/codeguy/Slim/blob/master/composer.json
• https://github.com/silexphp/Silex/blob/master/composer.json

etc...

All examples of .gitignore that I have seen for symfony2 projects allso dont ingore composer.json and composer.lock files

• https://github.com/github/gitignore
• http://symfony.com/doc/current/book/installation.html

Extract of the provided installation documentation :

Using Source Control If you're using a version control system like Git or Subversion, you can setup your version control system and begin committing your project to it as normal. The Symfony Standard Edition is the starting point for your new project. For specific instructions on how best to setup your project to be stored in Git, see How to Create and >store a Symfony2 Project in Git. Ignoring the vendor/ Directory If you've downloaded the archive without vendors, you can safely ignore the entire vendor/ directory and not commit it to source control. With Git, this is done by creating and adding the following to a .gitignore file: 1 /vendor/ Now, the vendor directory won't be committed to source control. This is fine (actually, it's great!) because when someone else clones or checks out the project, they can simply run the php composer.phar install script to install all the necessary project dependencies.

[maxailloud]

You're right, but for them you're not supposed to modify this file. For Claroline we can add/remove/update dependencies as we need to, it's our project after all.

For Symfony and Silex you won't modify it, you never modify the framework you're using.

Library you're using and you project is different, and so on for the files management in it.

[hakre]

@maxailloud I might be shooting dead horses here, however if I may direct to the Basic Usage Instructions of Composer:

Commit your application's composer.lock (along with composer.json) into version control.

That is in bold within their own docs. You can find it here:

• https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file

You can keep any habits you have, I don't care, was just spotting this and thought it's worth to leave some documentation for the interested reader.

So if you ship your platform as a dependency you might want to have it under version control incl. it's own dependencies.

[stefk]

@hakre, the only reason composer.* files haven't been put into vcs from the beginning (as it should be) is that this project uses a plugin system, which allows development teams to add or remove plugin packages according to their needs -- i.e to diverge from the original set of dependencies.

[hakre]

Ah, I see. Perhaps those plugins then should be configured differently. But I understand the problem now, you need to share composer.* between upstream and all your users individually.

Interesting. Does this work well? I dunno if those composer installers are an option for you here, probably those pre-install scripts jumping / hooking onto a second composer file. Something like an override.