Composer customizations via Poser

[lgedgar]

• Version of CORE?

latest

• Issue with Office, Lane, or both?

Office, maybe also Lane?

• Is this [mostly] a bug report, feature request, or question?

question

Trying to use Poser and sure enough want to install custom packages via composer. Which brings me back to the question of how to do that and not upset CORE and its own composer.lock file, i.e. assuming I want to keep running "upstream + poser" and not fork anything.

Good news is, I think I might have found the answer. But wanted to run it by others and/or just let them know.

Instead of assuming the composer.json from CORE is "primary" I'm assuming the one from Poser is primary. The latter then "merges" the one from CORE. Then in fact the composer.lock from CORE is ignored and only the composer.lock from Poser is used.

Maybe helpful to see the example I'm working with: corepos-demo-poser/composer.json

So far that example is "hard-coded" to live in e.g. the poser folder which is sibling to IS4C - a bit unfortunate but since a Poser repo should be org-specific, hopefully not terrible (I mean, can hard-code to whatever is preferable).

Anyway FYI but definitely curious if there is something wrong with the approach, or if it spurs other ideas etc.

[gohanman]

That looks pretty slick. The only problem I can imagine is if both projects wanted to install a different version of the same package, but that would almost certainly be problematic regardless of how composer.json file(s) are managed.

[lgedgar]

Yeah actually already ran into that sort of, cf. #1186. Could be a problem depending on which 3rd party packages are needed in Poser, dependencies of those may conflict with CORE requirements.

To me it seems like if Poser is a viable solution to the "composer customizations" problem, then maybe can remove some things from CORE default composer.json etc. Again cf. #1186 for example of that. But maybe should let this play out a bit first..?

[gohanman]

Would Poser ship with composer.json.default or similar to avoid replicating this issue? Or is the idea that the Poser repo would be a lightweight shell and further customizations get installed from other repos via Composer?

[lgedgar]

I have something like this in mind:

Day 1 I am part of some grocery co-op startup and I install CORE upstream/master with no mods.

Day 90 I want to use the IncidentTracker plugin with Slack. CORE no longer requires all dependencies for that so I create a Poser project to customize packages. (More on that below.)

Day 120 I decide I need to customize receipt printing so I create a new Lane plugin within my Poser project.

etc. the idea is primarily to avoid forking upstream. Any given Poser project can do whatever it likes to "collect" the needed functionality. In most cases this is writing new from-scratch plugins, which may require additional 3rd party packages (probably most often they would not). Perhaps in other cases it will make sense to have additional public repos out there with certain collections of generically-useful things, that could be brought into a Poser project (git submodules?). But it likely would make sense to just keep such things in CORE upstream and avoid the spaghetti.. (GitStatus is one such plugin separate from upstream, and so far I'm git-cloning it into my Poser dir but adding office_plugins/GitStatus to the Poser .gitignore file.. Unfortunately installing this one with Composer is "worse" because of the special CORE/Composer installer plugin, which breaks with Poser..)

Technically a Poser project has no structural requirements (yet?) other than those outlined in #1074, namely:

• lane_plugins folder
• office_plugins folder

But neither of those are required, CORE just knows to look for them if its Poser path is defined.

I'm thinking now that it may often be the case, that a Poser project starts with nothing more than:

• composer.json
• composer.lock

The latter being auto-generated by Composer of course, but since it's now the "authoritative" lock file it should be committed to Poser repo. The composer.json file would start out like:

{
    "name": "my-org-name/poser",
    "description": "CORE-POS customizations for My Org Name",
    "require": {
        "wikimedia/composer-merge-plugin": "^2.1"
    },
    "extra": {
        "merge-plugin": {
            "require": [
                "../IS4C/composer.json"
            ]
        }
    },
    "config": {
        "component-dir": "../IS4C/fannie/src/javascript/composer-components",
        "vendor-dir": "../IS4C/vendor",
        "allow-plugins": {
            "composer/installers": true,
            "oomphinc/composer-installers-extender": true,
            "corepos/composer-installer": true,
            "wikimedia/composer-merge-plugin": true
        }
    }
}

One sort-of-gotcha is that docs may need to be clear about "where" you should run Composer commands. So far that has been the CORE (IS4C) folder, and that still works until you add Poser, then you must run Composer from that dir instead.

So as for whether Poser should "ship" with a default, I was thinking there is no "base" Poser repo from which to fork, rather each Poser repo is created entirely from scratch as needed. And if it needs a composer.json file then yes, the above template should be available e.g. as part of docs? But within the Poser repo itself there's no need for a default, it just needs to contain the "actual" production-ready files.