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.
Rowan Tommins
[IMSoP]
