Hi, I'm currently exploring deployments using GIT and Composer would be a great tool for this.
So +1 for me :) Le 01/10/2014 14:05, Doursenaud, Raphaël a écrit : > 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 > <mailto: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 <mailto:marcos...@gmail.com> > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org <mailto: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
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
