> On Jun 30, 2024, at 4:28 PM, Michael Morris <[email protected]> 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
What?!? No good WordPressista would be caught dead using an uncapitalized "p."
https://developer.wordpress.org/reference/functions/capital_p_dangit/
Have you no shame? ;-)
> 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.
But seriously, I think the issue is not the CLI usage as Composer could be included as library in
PHP if it made sense. The issue is different plugins loading different versions of the same
dependencies, something that Composer delegates responsibility to the developer to resolve because
PHP does not provide package-level scoping...
> * 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.
Yes, package-level scoping would be useful.
However, maybe we could first focus on how to get "package" scope as a much smaller scope
as a starting point? No pun intended on "scope." :-)
Constrained scoped should be orthogonal to namespaces, and also thus support namespaces as both
Rowan and Larry have explicitly said they want.
> 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.
I (obviously) like the idea of a .php.mod or differently named file that PHP would get
site and/or directory information from. Such as pre-compiled equivalent to a `.phar file, but then
it would not be a text file as you have proposed. I do think having the version of PHP expected
would be interesting which would define the author's intent — assuming they maintained it —
and could allow multiple versions of PHP running on the same server.
However, I do agree with Rowan that trying to create new functionality that differs from Composer is
likely destined to failure. And if PHP allowed package-level scoping then Composer could likely
resolve the issues that WordPress faces without needing a new way to manage packages.
(I really wish Composer supported direct package reference via URL rather than only supporting
registries. But I digress.)
-Mike