I've recently been looking at progressing MDL-49672, an issue to transition to use of Composer for management of libraries with Moodle core.
At this time I have modified the original proposal such that:
- we only support composer for core and not plugins;
- we do not include the content of the vendor directory within git repositories; and
- we do include the content of the vendor directory in the official downloads.
While I hope that we can possibly offer official support for Composer in third-party plugins in the future, unfortunately this seems to be one of the biggest barriers to adopting Composer in Moodle at this time.
As a result, these changes are less likely to affect most developers, but I would appreciate any comments, notes, critiques, and observations with my proposal.
Thanks for your time,
Just to say that I've read through the tracker issue, and I think your new proposal sounds sensible. In particular, I think its important to retain the "Download and run" ability with the official packages, so including the vendor directory in these packages is a good idea.
One thing I would say is that there needs to be very clear documentation about which composer commands to run when installing/upgrading, so that you always get the correct, fixed versions of libraries, and don't accidentally upgrade to untested versions. I also assume that there will be separate commands for installing dev tools (Behat, PHPUnit and so on)?
The only thing I'm not clear on is the core vs plugins issue, could you summarise why we'd support it in core, but not in plugins?
Thanks for the feedback.
Yes -- I think that the retention of the "Download and run" approach is important, and we would have to ensure that the documentation is clear.
Essentially installation is just a case of running composer install --no-dev. This makes use of the composer.lock file that we ship with Moodle.
Installation of developer components is just a case of removing the --no-dev argument.
The reason that I am proposing that we do not support composer in plugins yet is for several reasons:
- it's unclear how we should handle potential conflicts between the two. If one plugin demands version X of a dependency, but another plugin demands version Y, what should happen?
- same question with regards core and plugins?
- we need to look at how we handle installation of all plugin dependencies in a sane fashion. I'm aware that there is a wikimedia dependency for exactly this purpose so this may help solve the issue
- it would be good to solve any potential issues in core before we roll out to plugins
Personally I would like to see us roll this out to plugins too, but I think we may need to do this in a two-step fashion initially.