Problems with composer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with composer

Laurent De Coninck
Hello guys;

Since it's my first e-mail on this mailing list, Let me introduce myself.
I'm Laurent from Belgium and I'm a PHP developer for a couple of years. Before (I developed in JAVA). I studied the development and management at school.
I already contributed to dolibarr in the past and I'm maintaining 2 modules for my organisation.

Now the let's begin with the object of this e-mail :

* How are you dealing with composer ? 
* Why don't you use the autoloader ?
* If you are loading each package manually on the pages what's the advantage of using a tool such as composer ?

Kind regards

De Coninck Laurent
https://github.com/laudeco


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problems with composer

Laurent Destailleur (aka Eldy)
Currently we are not using composer for Dolibarr.
We made experiment with it but it brings a lot of troubles (autoload create a lot of conflicts with other external modules that use autoload to to load other librairi version, it install 80% of files that we do not use/need, it needs to maintain another tool).
Currently we prefer to promote a more universal solution, based on "git clone" to deploy/upgrade an install/version.

Le ven. 1 févr. 2019 à 08:46, Laurent De Coninck <[hidden email]> a écrit :
Hello guys;

Since it's my first e-mail on this mailing list, Let me introduce myself.
I'm Laurent from Belgium and I'm a PHP developer for a couple of years. Before (I developed in JAVA). I studied the development and management at school.
I already contributed to dolibarr in the past and I'm maintaining 2 modules for my organisation.

Now the let's begin with the object of this e-mail :

* How are you dealing with composer ? 
* Why don't you use the autoloader ?
* If you are loading each package manually on the pages what's the advantage of using a tool such as composer ?

Kind regards

De Coninck Laurent
https://github.com/laudeco

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problems with composer

Laurent De Coninck
In reply to this post by Laurent De Coninck
Hello eldy;

Thanks for the reply it's the first time, I hear that someone in the PHP world don't like composer :o. Anyway I understand your point of view. Let me propose something via a PR.

Kind regards
L.

De Coninck Laurent
[hidden email]

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problems with composer

Mistral Oz
Hi,

I agree on the fact that this is not a small change, there will probably be several impacts to manage.
However about, "git clone" solution, i'm not aggree: i think it's a very poor solution (it's work but there is a lot of disadvantages for maintenance).

I'm currious of an other solution from Laurent DC's PR (i have not used enough composer to know if it can be better : how to deal with module dependencies ? with integrity check ? and other...).


Mistral Oz
02 30 96 35 58 - 06 62 00 46 81
Mes dispos : http://ozm.fr/dispo.php



De: "Laurent De Coninck" <[hidden email]>
À: [hidden email]
Envoyé: Dimanche 3 Février 2019 18:06:20
Objet: Re: [Dolibarr-dev] Problems with composer

Hello eldy;

Thanks for the reply it's the first time, I hear that someone in the PHP world don't like composer :o. Anyway I understand your point of view. Let me propose something via a PR.

Kind regards
L.

De Coninck Laurent
[hidden email]

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Problems with composer

Laurent Destailleur (aka Eldy)
I take several month to make this answers. But it is a sensible topic, so i have to compile a lot of point of view to make the good answer.

Well, does a user has to deal with the libraries dependencies of an application ? A "developer" user yes, and non technical end user, no.
In Dolibarr, all required libraries are embedded with a combination that is guaranteed by the project and the Continuous Test Integration platform.
Only the combination provided by dolibarr project and tested by continuous integration and beta sessions can be supported. Changing one version of an external libraries breaks dolibarr 90% of time, so it is not recommended to manage each library version independently by yourself. Most users and integrators should not have to think about this :  This is the job of the software editor not he user.  Dolibarr is one and only one package that works with no need for extra libraries. This is same philosophy than the new generation of packager (like snap, flatpack) are working now (thanks to them to save time of users and integrators). 
Old way of working using automatic dependency download and even downloading sublibraries not required is just a dangerous way of working. It is great on a developer station. But Dolibarr packages are designed for users, not for developers.

Lets take the example of the debian package that was officialy integrated into debian :
Debian packaging is a similar system than composer in a sense that it uses an old school packaging system (where each components has a version minimum and each application is built by adding tons of other components according to automatic dependencies definition). This system creates tons of dependencies on very large projects and of course each micro-libraries evolves without taking into consideration the projects that consume/use them, above all when the project is a project that consume a project that consume another one that consume another one, etc.... We did provide an official Dolibarr debian package that was officially available in debian distribution, but after spending a lot of money (several thousands of euros workign with the most famous official debian packagers and debian leaders' companies) and after several years of work, the conclusion was that is was not possible to provide an official debian package that is as secured and as easy to install and to maintain than the "standalone dolibarr package" with same level of features (a standalone package is packages using the new generation of package policy, that does not depends on the external environment or on a dependency tree that changes on each different station each time a sub library change. a standlone package is just a package that match 100% like the editor wants, with even 1 byte of difference). Such standalone packages just always works whatever is the system your install on it, whatever are the changes done on external libraries done by libraries maintainers and it does not change nothing on what is already installed, keeping all existing application working the same way with a 100% guarantee. The only solution to keep the same quality with the debian old school packing compared to a autonomous packaging that embed all dependencies was to become the maintainer of packages of all dependencies Dolibarr depends on. The debian project encourages us to do it. So we did it !
And we become the packager of debian TCPDF library for example, then we add to become also the packager of some javascript libraries, and then another one, etc... Even by becoming the official packager of project developed by other team (this was stupid yes, but we have to do it to guarantee that packages combinations was working together), we had to removed a lof of feature in Debian official package because the combination of libraries provided by dependencies tree was not the one we need, some features were missing or broken when each libraries were used together in same application. Also size of installed application become enormously ridiculous due to the ton of dependencies installed, that nobody need/want. And i don't speek about security (the more you add library your don't need, the more you introduce holes).
We finally stopped the objective to provide official package into a debian distribution where dependency were managed by an external system. I pushed myself the project in this direction and we failed. We have earned.
Now we provide a debian package where all dependencies are embedded in the Dolibarr package, dependencies are the result of the choice of the project and only the choice of the project. All files are validated and tested by automatic integrity platform of official project and also by beta releases and testers. There is even 1 file we don't want/need. We saved so much time doing like that (several hours of work each week during several years, only for myself), solve so many problems we got, without seeing any disadvantages, that I still don't known why we keep so many years to try to use a dependency system where we don't need.

Yes, composer is a little bit better than Debian dependency system (for example, each application can install its own version of library, we have more choice/option to force range of version we want/need), but it is an example to explain why a "multi-level dependency" can be bad for a very large project. The size of a Dolibarr project is nearly doubled due to stupid and unwanted dependencies. Combination of libraries we need is often just not possible to install due to dependencies conflict on sub-libraries of such libraries, and this sub libraries that are in conflict are even never used in our project context ! Why installing them ? We just introduce bugs, security holes and e have different installation with different combination of subversion of libraries that was not the one tested and qualified ? We want this on a developer station but we want this opposite on and end user stable production server.

We made an error with Debian package trying to persist several years, spending a lof of money, we won't make same error with composer and we won't persist after seeing all the bad effect that an "automatic dependency package system" brings even if this is a good tool for a developer station), with no gain. So composer experience has also been abandoned. As often, it is the proof of the experience that rule on Dolibarr (we test both and we keep what is better). May be we will try it again later, but, currently 99% of NOT experienced users install Dolibarr with an "autoinstaller" dolibarr package (doliwamp, dolideb, dolirpm, ...), composer is not able to make what such package do (like installing a full webserver or editing windows registry), and most experienced users and integrator (at least among the one i can speak about) are using "git clone" with a so higher satisfaction compared to composer that the task to provide a composer package again is now a very low priority. More suitable solutions like "snap" or "flatplack" seems more interesting but let's see how contributions evolves and package system popularity evolves. All contributions are still welcome if they brings more pro than cons, but currently composer brings more cons than pro. But things can change quickly in the computer world.


About the integrity check of a Dolibarr installation, there is also a native integrated feature of Dolibarr to check this (into home - setup - dolibarr - file integrity) and this check includes external libraries, so if you change a library with a version that is not the one expected by project, you can, but Dolibarr can detect your are using a not validated/tested combination (one byte modified in one file is enough) and the file integrity checker will report it. This feature can be used by any not technical user from the graphical interface, it is often enough for a user. For integrator using git, the git status can also do it. Of course both methods are always available and can be combined, for a best world ! 

The questions of external module is different. The compatibility of a module with a dolibarr version is guaranteed by the module developer not by the Dolibarr project, and the developer has the feature into the dolibarr module installation process to guarantee that its module is not installed if it does not follow the Dolibarr version the module developer has validated it for.



Le dim. 3 févr. 2019 à 19:11, Mistral Oz <[hidden email]> a écrit :
Hi,

I agree on the fact that this is not a small change, there will probably be several impacts to manage.
However about, "git clone" solution, i'm not aggree: i think it's a very poor solution (it's work but there is a lot of disadvantages for maintenance).

I'm currious of an other solution from Laurent DC's PR (i have not used enough composer to know if it can be better : how to deal with module dependencies ? with integrity check ? and other...).


Mistral Oz
02 30 96 35 58 - 06 62 00 46 81
Mes dispos : http://ozm.fr/dispo.php



De: "Laurent De Coninck" <[hidden email]>
À: [hidden email]
Envoyé: Dimanche 3 Février 2019 18:06:20
Objet: Re: [Dolibarr-dev] Problems with composer

Hello eldy;

Thanks for the reply it's the first time, I hear that someone in the PHP world don't like composer :o. Anyway I understand your point of view. Let me propose something via a PR.

Kind regards
L.

De Coninck Laurent
[hidden email]

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev