On Sun, Jun 30, 2024, at 22:28, Michael Morris wrote:
> So let's take another crack at this based on all the points raised in the
> thread. This should also underline why I don't consider this an RFC - I am
> iterating until we arrive at something that may be refinable into an RFC. And
> I say we because without the aid of those in this conversation I would not
> have arrived at what will follow.
>
> Before I continue I would like to apologize for being somewhat irritable.
> We're all here because we enjoy using this language and want to see it
> improved and prevent bad changes. Opinions will differ on this and in the
> heat of the moment of arguing a point things can get borderline.
>
>
> Returning to a point I made earlier, Composer isn't used on Wordpress. I
> went over to the Wordpress discussion list and read over why, because that
> discussion provides clues to what kind of package management may be
> adoptable. I think the largest point is that Wordpress should be usable
> without ever resorting to using the command line. Yes, it does have a command
> line tool - wp-cli - and it is powerful, but using it as an administrator of
> a Wordpress site is not required.
>
> The largest block to composer's inclusion in Wordpress is the inability to
> run multiple versions of a module. Yes, it's a mess when this happens, but if
> you're an end user, you just want your plugins to work. If one plugin that
> no one has updated in a year that you're using is consuming version 2 of a
> package, you're gonna be annoyed at best if the module stops working when you
> install a new plugin that is using version 3 of the same package and has a BC
> break in it. Composer can't resolve this easily.
>
> There are WordPress plugins that use composer - I have a couple in the
> website I'm working on. But they accomplish the inclusion of composer by
> redistributing the packages, and using a utility called brianhenryie/strauss
> to monkey type the entire included package into the plugin, changing the
> namespace of the entire package to something different. The approach works,
> but it's ugly. In any event, the plugin that results from this carries a
> copy of the code from packagist rather than sourcing the code from packagist.
>
>
> -- IMPORT --
>
> The import statement is for bringing in packages. It needs to be able to
> deal with:
>
> * Extensions - the existing and oldest of packages for PHP
> * PECL Extensions
> * Phar Packages
> * Composer Packages
> * PHP Modules - this is the new module system that has dominated the
> conversation, but in this iteration it's going to be broken away from import
> to some degree in this iteration.
>
> Today we'll look just at composer.
>
> Now import needs to load packages in a manner that allows different versions
> to be run concurrently. A PHP application such as Wordpress should be
> distributable without needing to use the command line. That is, if WordPress
> leverages this in any way, they don't have to give up their famous 10 minute
> quick install.
>
> Some terms here to keep myself from getting lost (let alone anyone trying to
> read this).
>
> * APPLICATION - This is the overall application - WordPress, Drupal,
> BobbysFirstFramework, etc. - that is doing the import. This code is on the
> root scope.
> * ROOT SCOPE - This is where the global variables and the namespaces as we
> know them exist. Contrast this with
> * PACKAGE SCOPE - Each package brought in with import gets its own package
> scope. This is a distinct behavior from Include/Require. I think each package
> scope will need to be on its own request thread, but this is an
> implementation detail I can't speak to with any authority. The goal is
> whatever happens in a package stays in the package. If two different
> packages want to define /foo(), they can.
>
> When a package is imported the parser will look for a `.php.mod` file at the
> root of the package. Among other things, this file details what type of
> package it is and where to mount it by default in the namespace of the ROOT
> SCOPE. So,
>
>> GIVEN a package with this .php.mod file
>>
>>> package MyModule
>>
>> WHEN I issue this import in an application
>>
>>> import "MyModule";
>>
>> THEN I should be able to access a method in that module with this code
>>
>>> \MyModule\foo();
>
> Aliasing is an option - `import "MyModule" as BeerModule` will make the
> methods accessible in the root with \BeerModule\foo();
Just to challenge you a bit here. The language already has `use` for this. Does
`use` stay or is it replaced with `import` and why not just change the meaning
of `use` in a package context?
>
> Unlike require/include import is sensitive to the namespace it is in for
> mounting. So
>
>> namespace Trees;
>> import "MyModule";
>>
>> MyModule\foo(); // works
>>
>> \Trees\MyModule\foo(); // needed from another namespace.
>
> That said, with aliasing an absolute namespace for the module can be assigned.
>
>> namespace Trees;
>> import "MyModule" as \MyModule;
>>
>> MyModule\foo(); // works if my understanding of existing namespace
>> resolution rules is correct.
>> \MyModule\foo(); // also works.
>
> Now, with that in place, let's crack a tougher nut - handling a composer
> package. By default composer is designed to set up an autoloader, then
> resolve symbol references as they come up. This works until you have two
> packages that want the same symbol reference - which will most frequently
> occur with incompatible versions of the same package. So our puzzle here is
> how to allow composer to do its thing without rewriting it. We'll deal with
> admittedly the hardest case first - importing a package whose maintainers
> have taken no action to make it compatible with this new system.
>>
>> import "composer://packagist.org/packages/twig/twig#v3.10.3" as
>> TemplateEngine
>
> The reason for that alias and not "Twig" is because the mounting point comes
> before the internal namespace of the file. This is unavoidable with this
> scheme
>
> The URL there is "loader://package_url". PHP by default will know what the
> composer loader is. It will look to see if the user has globally installed
> composer already and use that, otherwise it will locally install composer for
> the project, initialize it, download the package and have composer resolve
> the package ending in setting up an autoloader that is only invoked within
> that package.
Adding this after I just wrote the below book. It started out simple enough and
it drives me crazy when people crash my proposal with a counter-proposal. So,
by all means, take it with a grain of salt ... I kinda went overboard thinking
about it.
I think composer and friends are a moot point. If we go a bespoke way for
everything, we end up with a mess. What about creating "hooks" that things like
composer can "register" an installer at? For example, we could define a
"WELL_KNOWN/installers/composer/hooks.json" (I'm gonna steal a bunch of ideas
from kubernetes from here on), where WELL_KNOWN is some engine-specific
directory (like where the php.ini file is). Basically, any installer can
register an installer by creating a directory in WELL_KNOWN/installers of which
an installer might look like the following for composer:
WELL_KNOWN/
installers/
composer/
hooks.json
composer.phar
cache
and hooks.json could have a schema of something like:
{
"name": "composer",
"version": "4.5",
"executable": "./composer.phar",
"scheme": "composer",
"command": "install-package-module"
}
Then the engine can scan these directories and read each hooks.json. Then when
it gets to your example above, it sees the scheme "composer" in the URL, looks
for an installer with that name, and calls the executable with some arguments
(the command, the "URL" aka the package, current directory, etc). So, it might
call composer with something like:
/WELL_KNOWN/installers/composer/composer.phar install-package-module
packagist.org/packages/twig/twig#v3.10.3 /app/public
The command is expected to dump the file to stdout -- which PHP then pipes to
wherever it is supposed to go (as you mention below).
At this point, the user may not know a single thing about composer or how it
works, or anything, really. As far as they are concerned, they said they wanted
an import and they got one. However, there still exists a bunch of
composer-specific scripts, etc. In this case, we make new WELL_KNOWN types. For
example, we can have "script-runners" that can be registered so you can just do
"php run composer test" and it will run `composer test` for you. If you want
something shorter, you can just add `alias composer="php run composer"` to your
shell and bob's your uncle.
This is basically how kubernetes handles networking, disks, etc. so that the
entire thing is completely swappable and extendable. So, we know the idea is
sound and "just works," we just need to customize it for php.
— Rob
