30,997
edits
Language and development rules: Difference between revisions
Jump to navigation
Jump to search
m
→About composer
m (→About composer) Tag: 2017 source edit |
m (→About composer) Tag: 2017 source edit |
||
| Line 636: | Line 636: | ||
This is not a good idea as it is just technically not possible for the following reasons: | 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'''. 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, mainly because of bugs into original project. 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'''. 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, mainly because of bugs or architecture error into original project. 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. | ||
* Third point is also problems with the dependency system: When you install an external library this library has dependency and each of this depency of depencies are constraints with each other and with PHP version. Library L1 is compatible with PHP x to x+n and library L2 is compatiblewith PHP y to y+m, etc... To have an application working correctly, you must find a PHP version that will be common to all the required packages. But when you are using a large number of high level libraries, it means you are depending on a very large number of low level of libraries (because each high level libraries has a lot of medium level libraries as dependencies that has a high number of low level dependencies). And when this number is very large, the number of total dependencies become so large that your reach a situation where the number of PHP versions that are common to all of them is very low, and even does not exists at all (there is no version that is compatible with ALL packages you need because each sub-project depreciate its PHP version with its own roadmap without taking care of which child or parent dependency use it). But Dolibarr must works for every body whatever is other project roadmap and on a largest as possible number of PHP versions and not just on one or two given version of PHP. Compatibiliy must also be guaranted during a very long term (an ERP is not a software we can change every year). | * Third point is also problems with the dependency system: When you install an external library this library has dependency and each of this depency of depencies are constraints with each other and with PHP version. Library L1 is compatible with PHP x to x+n and library L2 is compatiblewith PHP y to y+m, etc... To have an application working correctly, you must find a PHP version that will be common to all the required packages. But when you are using a large number of high level libraries, it means you are depending on a very large number of low level of libraries (because each high level libraries has a lot of medium level libraries as dependencies that has a high number of low level dependencies). And when this number is very large, the number of total dependencies become so large that your reach a situation where the number of PHP versions that are common to all of them is very low, and even does not exists at all (there is no version that is compatible with ALL packages you need because each sub-project depreciate its PHP version with its own roadmap without taking care of which child or parent dependency use it). But Dolibarr must works for every body whatever is other project roadmap and on a largest as possible number of PHP versions and not just on one or two given version of PHP. Compatibiliy must also be guaranted during a very long term (an ERP is not a software we can change every year). | ||