Open lgedgar opened 1 year ago
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.
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..?
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?
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
folderoffice_plugins
folderBut 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.
latest
Office, maybe also Lane?
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 thecomposer.lock
from CORE is ignored and only thecomposer.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 toIS4C
- 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.