TL;DR: Composer is good, please vote up! Another great feature of having dependencies managed is that we could leverage services like https://www.versioneye.com to keep up with upstream changes (updates/bugfixes/security) without relying on some human auditing the libraries once in a while.
Anyway, I've already expressed my views. Thanks Marcos :) 2014-10-01 11:29 GMT+02:00 Marcos García <marcos...@gmail.com>: > Hi all: > > I've recently experimented with Composer and delegating dependencies > management to it. You can see the result in > https://github.com/Dolibarr/dolibarr/pull/1759 > > 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* > > marcos...@gmail.com > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > -- *Raphaël Doursenaud* Directeur technique (CTO) Expert certifié en déploiement Google Apps <https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist> +33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10 -- <http://gpcsolutions.fr> http://gpcsolutions.fr Technopole Hélioparc 2 avenue du Président Pierre Angot 64053 PAU CEDEX 9 SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921 <http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions>
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
