On Mon, Jun 2, 2025, at 9:44 AM, Rowan Tommins [IMSoP] wrote: > On 2 June 2025 14:27:45 BST, Larry Garfield <la...@garfieldtech.com> wrote: >>Were we to do that, then the consumer container-loading needs to take any >>potential module-definition into account. Eg, if one class from a module is >>pulled into a container, all of them must be. > > You wouldn't containerize "something from a library", any more than you > containerize "part of Nginx". You create a container, and put a bunch > of stuff in it *that doesn't know it's running in a container*. A Linux > container doesn't know that Nginx requires a bunch of shared libraries > and daemons, it just creates a file system and a process tree, and lets > you do what you like with them. > > Let's say I'm writing a WordPress plugin. It's just a bunch of files on > disk, some of which I've written, some of which I've obtained from open > source projects. Maybe there's a giant file with lots of classes in, a > vendor directory I've generated using Composer, some Phar files, and > some fancy modules with metadata files. Maybe I distribute an install > script that fetches updated versions of all those things; maybe I just > stick the whole thing in a tar file and host it on my website. > > I want to have WordPress load all that code as part of my plugin, and > not complain that somewhere in there I've called a class > Monolog\Logger, and that name is already used. > > I don't need WordPress, or PHP, to know whether that class is "really" > a version of Monolog, or how it ended up in the folder. And I don't > need twenty different containers for all the different things in the > folder. I just need to put *that whole folder* into a single container, > to separate it from someone else's plugin. > > The container somehow creates a new namespace root, like a Linux > container creates a new file system root. The code inside uses require, > autoloading, module definitions, etc etc, but can't escape the > container. > > Then in some way, I define what's allowed to cross the boundary between > the main application and this container - e.g. what parts of the > WordPress API need to be visible inside the container, and what parts > of the container need to be called back from WordPress. > > And that, if it's possible at all, is the plugin use case sorted. No > changes to Composer, no need to rewrite every single PHP package ever > written. Probably some caveats where dynamic code can accidentally > escape the container. Completely separate from the kind of "module" you > and Arnaud were experimenting with.
Well, now you're talking about something with a totally separate compile step, which is not what Michael seemed to be describing at all. But it seems like that would be necessary. At which point, we're basically talking about "load this Phar file into a custom internalized namespace", which, from my limited knowledge of Phar, seems like the most logical way to do it. That also sidesteps all the loading and linking shenanigans. Doing it that way, as a Phar-loading-wrapper, is probably the most likely to actually be viable. I'm still not sure I'd support it, but that seems the only viable option so far proposed. --Larry Garfield
