Hi all:
If you are not familiar with Composer, it does allow removing 3rd party code from the source and updating dependencies with a single "composer update" command. If you want to "lock" the version of the dependencies for your project, just do "composer lock" and developers should only use "composer install" to install the exact version your project needs to work properly. Versions are stored in a composer.json file.
I'll put some opinions made by Laurent D. an Raphaël D.
Laurent said:
I don't think we should composer. I know a lot of people think it is a good practice. When editing a software i think the opposite. It is not composer to decide which version of library we must provide or "validate" for a full dolibarr release. Only one version must be tested/validated per version of dolibarr.
Using composer bring more problem than solution (in fact i don't see any good thing with using dependencies into a software you edit). This may be a good thing for an os to manage software but not for a software to manage libraries. There is few effect of os into a software but a library onto a software just can't be separated.
We must be sure of wich version is used. We must also be able to patch them (as we did into dolibarr_changes.txt)
Also using composer is just a headache when we want to build a package.
Also when externalisation of lib must be done (for example when we have no choice for debian package), the we must be able to do it library per library (like it is already done). So using a global constant DOLIBARR_VENDOR_ROOT is not a good solution (there is already a constant for each library so no need to add one more global). Package debian that force to use external library is a good example of all problems we have when using an external composer: We finally had to remove completely some feature into debian package (not the one provided by dolibarr but the one that was pushed into debian official sources) just because external library was changing to often with a change in behaviour that we couls not control.
Definitely managing dependencies automatically is not a good way of working for a "software editor". It consumes a lof of time and result is a not stable software (debian package is a good example. The package pushed into official debian with dependcies managed by a composer like is just a pain and not reliable, package debian provided by dolibarr with embeded libraries just works like it should).
Other people may try to make my mind change i have so many bad experience using composer like feature into software buidling solved just by stopping using it that probability to have this is nearly 0% currently.
Raphaël said:
Let me politely disagree. The problems you mention are not composer's fault but the way you think it should be used (or the way most people tend to use it).
Composer vastly simplifies dependency management by locking specific version of the dependencies to your code (in the composer.json or through the composer.lock that should be committed to the tree), while being explicit about it and helping managing updates smoothly by choosing precisely the version(s) you want and/or allow.
I'm not in favor of a new vendor path either. Our include path (htdocs/includes/) already does exactly this for us. We don't even need any autoloader (yet).
I'm also strongly in favor of keeping the composed files in the revised tree, but composer purists may disagree.
I just use it as I use my OS package manager. It sorts dependencies out for me but I'm still allowed to overwrite or move some files if I feel like so.
Bottom line : this PR is not really good for us as-is but it can certainly be improved to better fit the Dolibarr project.
Cheers!
Laurent said:
The way you suggest to use it looks better to me. That's why i think we can have a composer.json file into root, but we must "lock" as you suggest the embedded version, once selected for a development target.
I said:
Hi all:
Versions are defined in composer.json file. As you can see, I used specific versions instead of the "*" or "~" parameter. That tells composer to download only that version, and composer.lock tells Composer to download those versions when doing the "composer install" command.
When I tell you that I had to update them is because they were too old to be available, which shouldn't be really a problem if we test them.
Whenever you want to update them, you edit composer.json to reflect the new version and do the "composer update" command. You can also tell composer to target a significant release of a minor version. For example: we track version 2.3 and 2.3.1 is used, but tomorrow 2.3.2 is released and composer.json wouldnt notice unless you tell him to download 2.3.2 version. You could do "~2.3" and it will download the latest one. "composer update" to update and "composer install" to install already locked versions.
The fact of separating the libraries from the code gives the advantage of not tracing other libraries' changes. That's a good advantage because "our" Git will only track our changes.
I did not remove the global constant you mention. Even if I don't like it because it is a source of a lot of problems (e.g. Debian having a super old version of an external library and Dolibarr requiring an specific version because of a bug). But that's not the point of the discussion.
¿Problems? Don't think so. A problem would be in a big Symfony project wether you can have a very complex map of dependencies that require around an hour and 3G of RAM to update them. This one is not.
Also, you are talking about "patching" external libraries. Patching external libraries is forking them. Also, it is better to modify them through extending classes than through modifying them directly as it is then harder to update because you have to deal with their changes and you changes over the file.
The vantages I find using Composer in Dolibarr are:
- Stop tracking other libraries changes
- Easier update of external libraries
- Better control of external libraries
- Separation of actual Dolibarr code and other libraries code
The discussion was moved to the mailing list to know your opinion about this change. This PR doesn't have to be the final one, was just an experiment to see if the change could be possible or not.
What do you think?
Regards,
Marcos García
address@hidden