Language and development rules: Difference between revisions

Jump to navigation Jump to search
m
Tag: 2017 source edit
Tag: 2017 source edit
Line 632: Line 632:


=About composer=
=About composer=
Composer is a tool to make deployment of PHP packages. Dolibarr is an application that use dependencies that are PHP packages so we could imaging to use composer to install Dolibarr.
Composer is a tool to make deployment of PHP packages and dependenciess. Dolibarr is a PHP application that use dependencies that are PHP packages, so we could imaging to use composer to install Dolibarr.
This is not a good idea as it is just technically not possible for the following reason:
 
This is not a good idea as it is just technically not possible for the following reasons:
 
* First, you must understand that composer is a tool '''to deploy a frozen image of a package''' (like is Docker). It is a tool to '''deploy''', not a tool to '''manage dependencies''' (event if some features exists for that): Dolibarr is an application that has a lot of dependencies, but for each of them, the Dolibarr project has to apply some patches to have the dependencies working correclty (for different reasons, see the file dev/dolibarr_changes.txt for full list). Each PHP dependency has at least one change to do to have it working correctly. So the image of a library L that Dolibarr needs is NOT the image provided into the composer package by the L project. After discussion with '''Nils Adermann''', the author of the composer package during the first OSFS congress (https://05f5.com) to get its point of view on this need for large projects, it appears that if a large project in this situation, the good way to use composer is to build ourself a very large package called "dolibarr" with no composer dependencies and all external libraries embedded into the same composer project so we can deploy all in one composer command, confirming that composer is above all a good "fast deployment system" but a bad "dependency manager". The dependency system of composer project was simply designed to use an exact version of a library and not to use a patched version of this library (it is even designed to avoid this).
* First, you must understand that composer is a tool '''to deploy a frozen image of a package''' (like is Docker). It is a tool to '''deploy''', not a tool to '''manage dependencies''' (event if some features exists for that): Dolibarr is an application that has a lot of dependencies, but for each of them, the Dolibarr project has to apply some patches to have the dependencies working correclty (for different reasons, see the file dev/dolibarr_changes.txt for full list). Each PHP dependency has at least one change to do to have it working correctly. So the image of a library L that Dolibarr needs is NOT the image provided into the composer package by the L project. After discussion with '''Nils Adermann''', the author of the composer package during the first OSFS congress (https://05f5.com) to get its point of view on this need for large projects, it appears that if a large project in this situation, the good way to use composer is to build ourself a very large package called "dolibarr" with no composer dependencies and all external libraries embedded into the same composer project so we can deploy all in one composer command, confirming that composer is above all a good "fast deployment system" but a bad "dependency manager". The dependency system of composer project was simply designed to use an exact version of a library and not to use a patched version of this library (it is even designed to avoid this).
* Second point is a different problem with the composer dependencies system: Each dependency on a library has itself a high number of sub-dependency. And all this sub-dependency has also a high number of dependencies that nobody can't control (there is always sub-dependencies on the libraries you use that are managed by a lower level dependency project). The result is that when you use composer to install the main library you need, you install (and you can avoid it) a ton of other packages you don't need. For example, Dolibarr is a 80Mb project with all its PHP dependencies. If you install it with composer (we suppose that the first point is not a problem), then the project reach the size of 300 Mb. Size of project is multiplicated by 3.5 with no reason.
* Second point is a different problem with the composer dependencies system: Each dependency on a library has itself a high number of sub-dependency. And all this sub-dependency has also a high number of dependencies that nobody can't control (there is always sub-dependencies on the libraries you use that are managed by a lower level dependency project). The result is that when you use composer to install the main library you need, you install (and you can avoid it) a ton of other packages you don't need. For example, Dolibarr is a 80Mb project with all its PHP dependencies. If you install it with composer (we suppose that the first point is not a problem), then the project reach the size of 300 Mb. Size of project is multiplicated by 3.5 with no reason.

Navigation menu