> On Jun 30, 2024, at 4:28 PM, Michael Morris <tendo...@gmail.com> 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
