Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124123
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial
 Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)
In-Reply-To: <CAEUnE0dSUY2VKji_o-AgQ-YZMf7viwCZh1sa8ScHdS7ihUgfUQ@mail.gmail.com>
Date: Sun, 30 Jun 2024 22:12:23 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F48C0C72-4C7C-4A5A-A974-08D1B4419731@newclarity.net>
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <CADK1yX+E9mvaM_CHJ8tmEx=O70hf8xasbvngh4wvNM8ce8KKGQ@mail.gmail.com>
 <B5DC69B8-E044-47FB-B81C-307E2C19CB66@newclarity.net>
 <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk>
 <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com>
 <CAEUnE0fNxSHN4QGfm6ETMVdE5Mcm1AEebmWs7i9xDNgcWnvQvw@mail.gmail.com>
 <39B496F8-062E-4848-9B3B-529BE8D3415A@newclarity.net>
 <CAEUnE0fOfU1tJNKXuBqbSm8jsp7gqe_JY-SiipdUKNztcx0Rog@mail.gmail.com>
 <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net>
 <CAEUnE0c0fW9xnQOtLgj1zTpvdfixSHuLeLA7HOqDTkpr4hJ84g@mail.gmail.com>
 <CAEUnE0dSUY2VKji_o-AgQ-YZMf7viwCZh1sa8ScHdS7ihUgfUQ@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 30, 2024, at 4:28 PM, Michael Morris <tendoaki@gmail.com> =
wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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.=20

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."  :-)=20=


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 =E2=80=
=94 assuming they maintained it =E2=80=94 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.=20

(I really wish Composer supported direct package reference via URL =
rather than only supporting registries. But I digress.)

-Mike=