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 639: | Line 639: | ||
* 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-dependencies have 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-dependencies have 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. Imagine the required library L1 is compatible with PHP x to x+n and the library L2 is compatible with 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, so here inside the intersection of the two ranges [x - x+n] and [y - y+m]. 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 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 different required ranges become so large that you reach a situation where the number of PHP versions that are common to all of them (hte intersection of all ranges) is very low, and even does not exists at all (there is no combination of version that is compatible with ALL packages you need because each sub-project depreciate its PHP version in 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 the as large as possible number of PHP versions and not just on one or two given major version of PHP. Compatibiliy must also be guaranted during a very long term (an ERP is not a software we can change every year), when low level libraries are changing requirement very often. | * 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. Imagine the required library L1 is compatible with PHP x to x+n and the library L2 is compatible with 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, so here inside the intersection of the two ranges [x - x+n] and [y - y+m]. 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 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 different required ranges become so large that you reach a situation where the number of PHP versions that are common to all of them (hte intersection of all ranges) is very low, and even does not exists at all (there is no combination of version that is compatible with ALL packages you need because each sub-project depreciate its PHP version in 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 the as large as possible number of PHP versions and not just on one or two given major version of PHP. Compatibiliy must also be guaranted during a very long term (an ERP is not a software we can change every year), when low level libraries are changing requirement very often. | ||
* Last point is about security: As we view in the second point, when using composer, a very high number of PHP files are installed even if you don't need them. Dolibarr is a critical application that need a very strict security policy. Requirement for security is at a high level (See our page [[Security_information]]). When using composer, you install a lot of files and small sub-project and sub-project of sub-projects where security is not considered as important than what we need on the Dolibarr project. If we make an analysis on a given period, the number of vulnerability reported on the whole project Dolibarr + files of external libraries when installed by composer (that we mostly don't need) is multiplicated by 20 compared to the number of vulnerabilities that are reported only in the scope of Dolibarr + external libraries when they are embedded in their minimal version manually). Such an increase is simply not possible and | * Last point is about security: As we view in the second point, when using composer, a very high number of PHP files are installed even if you don't need them. Dolibarr is a critical application that need a very strict security policy. Requirement for security is at a high level (See our page [[Security_information]]). When using composer, you install a lot of files and small sub-project and sub-project of sub-projects where security is not considered as important than what we need on the Dolibarr project. If we make an analysis on a given period, the number of vulnerability reported on the whole project Dolibarr + files of external libraries when installed by composer (that we mostly don't need) is multiplicated by 20 compared to the number of vulnerabilities that are reported only in the scope of Dolibarr + external libraries when they are embedded in their minimal version manually). Such an increase is simply not possible and some companies would simply not be allowed to use Dolibarr if we accept these due to a strict security requirements of their business. | ||
As we can see, composer, even if it was largely adopted by a lot of small projects, is far away from the state of the art. For all this reasons, it is just not possible to use composer so we keep the composer.json file in the project so we can use it for some development tests or make upgrade tests of some libraries with it, but we have renamed it by adding the extension ".disabled" to be sure that end users won't try to install or update their Dolibarr with it (in which case, the application will become unsecured and unstable). | As we can see, composer, even if it was largely adopted by a lot of small projects, is far away from the state of the art. For all this reasons, it is just not possible to use composer so we keep the composer.json file in the project so we can use it for some development tests or make upgrade tests of some libraries with it, but we have renamed it by adding the extension ".disabled" to be sure that end users won't try to install or update their Dolibarr with it (in which case, the application will become unsecured and unstable). | ||