Starting working with Composer using the Eclipse plugin. It’s similar to using Maven for Java. As an interpreted language, PHP builds are a lot simpler than Java. But I have to learn it, starting from scratch. The code I look at is easy to understand in familiar syntax forms, using familiar concepts. Knowing what to type is a different matter.

As a first project, I’m making a little library of user-friendly command line tools that will work with custom portable wallets that hold/retrieve encrypted password info. All the real work are things that exist in PHP libraries, so I’m learning how to connect & manipulate them. That’s a useful tool I wish to use for other things. But getting familiar with basic/modern PHP programming is the main thing.

There is really a tremendous amount of functionality in libs on https://packagist.org Being able to integrate most of them in an automated way, and many of the rest by cut in paste is attractive.

Composer does not solve the theoretical problem of different WordPress plugins potentially loading conflicting versions of the same library and somehow clashing. But that doesn’t seem to happen much in practice. If it did, WordPress could pretty easily write a plugin integration framework and the existence of Composer knowledge base for saying which libraries can be shared and are compatible would be a big help to that effort.

In the morning I read several articles talking about where to install composer/git & whether they should “manage” WordPress. Thinking it over, I would say this:

Every software mini-project could conceptual have these 3 states: early-devel, late-devel, and production/install. Define them for purposes of this discussion: production/install should have only the files actually used for production/install or for understanding/maintaining it in the relevent locations. To achieve that, developers in late-devel stage normally write some kind of install scripts, which move files from their development spot to their install spot. In early stage development, it is premature & counterproductive to be working on install scripts for things that will change. In early stage devel it is convenient to be able to run/test without install scripts, so things like git/composer go in the same directory trees.

“WordPress” installations can be simultaneously in different phases from different POV: e.g.WordPress itself & 3rd party plugins are in “production” but while the website development may be in early devel – add/removing/reconfiguring various plugins & themes. Or perhaps a particular plugin is in early devel. Then that tree should get it’s own git/composer treatment. Various developers have worked on moving WordPress sites between devel and production locations, but WordPress itself hasn’t integrated that support so far.