On 2 June 2025 14:27:45 BST, Larry Garfield <[email protected]> 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.
Rowan Tommins
[IMSoP]