Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124128
Precedence: bulk
MIME-Version: 1.0
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>
 <CAEUnE0fyOjQ4X_-X9nGqKnscUBPuJAV2PtPxdWJsRWJYLw+toA@mail.gmail.com>
In-Reply-To: <CAEUnE0fyOjQ4X_-X9nGqKnscUBPuJAV2PtPxdWJsRWJYLw+toA@mail.gmail.com>
Date: Mon, 1 Jul 2024 07:32:57 +0200
Message-ID: <CABdc3WoNoHw7f9Jhcy1QfieoXmUexx1VatmOr_aTEPH2FnxqbA@mail.gmail.com>
Subject: Re: [PHP-DEV] Packages Iteration 3: was Re: [PHP-DEV] [Initial
 Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ac1351061c28ee35"
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000ac1351061c28ee35
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

pon., 1 lip 2024 o 01:18 Michael Morris <tendoaki@gmail.com> napisa=C5=82(a=
):

> ...
> Applications
>
> The application is the root package. It is the package that imports to th=
e
> root namespace. When PHP is asked to parse a file it will look for a
> `.php-packages` folder, first in the current working directory then in
> parent directories.  If it doesn't find one, business as usual.  If we do
> find one we follow its directives about setting up an application
> environment.
>
> The `.php-packages` folder is where PHP will put package related code for
> the application at hand.  Code written explicitly for these changes will
> also put their package related files there - composer's vendor directory,
> composer.json, composer.lock, and so on - rather than putting those files
> in the site root. The folder is hidden to prevent web servers like nginx =
or
> apache from serving the files directly in any way.
>

First, you use the term Application then Site - decide.
Not all PHP applications are HTTP Applications, consider consumers, cron
tasks other daemons, these don't need the existence of either Nginx or
Apache.
Not all PHP HTTP Applications expose files to Nginx or Apache - most of
these I know like Rest API give ZERO access to any application file to
Nginx or Apache.


> The .php-packages directory will have a configuration file called
> `php.mod`.  This tells the parser:
>

You propose to move `composer.json`, `composer.lock`, and `vendor` into a
hidden folder with no good reason which simply adds more confusion.


> Let's look at what such a file might look like for Drupal. For the moment
> I'm going to use go.mod's syntax. The final syntax to be used, be it ini,
> yaml, toml, json, is a discussion for another time. The part to focus in =
on
> here is what type of information do we need.
>
>   package Drupal
>
>   php 10
>
>   registry //packagist.org/packages composer
>
>   init (
>     composer install
>   )
>
>   require (
>     ./vendor/autoload.php
>   )
>
>   imports (
>     //getcomposer.org/composer.phar
>   )
>

This looks like a completely new file format which simply makes
interoperability harder, consider tools like GitHub Dependabot, PHPMetrics
or other tools that analyze dependencies - what you propose requires
implementing a parser in userland or other languages the tool uses.


> The directives do the following:
> ...
>
* init is the command(s) to run before the application is started for the
> first time.
>

What is the use case for it I don't get it.
Many PHP Applications are distributed as a container image with all
dependencies already included.
How would it work with multi-threaded environments, which thread would be
responsible for running init? How do you solve concurrency problems then?


> If this theoretical version of Drupal moves its composer.json and
> composer.lock files into `.php-packages` then the autoloader doesn't have
> to be required in the index.php file.  Also, the application can be start=
ed
> without running `composer install`
>

`index.php` is just a common name for PHP HTTP Applications for modern
frameworks like Symfony and others that one lays in `public/` folder as an
entry point, often this is the only file in this directory.
If I understand your idea correctly you'd like a couple of I/O operations
on the filesystem to find the `.php-packages` directory in CWD else if not
in the parent directory and so on rather than directly pointing where it
is, right?


Cheers,
Micha=C5=82 Marcin Brzuchalski

--000000000000ac1351061c28ee35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Michael,</div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">pon., 1 lip 2024 o 01:18=C2=A0=
Michael Morris &lt;<a href=3D"mailto:tendoaki@gmail.com">tendoaki@gmail.com=
</a>&gt; napisa=C5=82(a):<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">...<br>Applications<br><br>The application is t=
he root package. It is the package that imports to the root namespace. When=
 PHP is asked to parse a file it will look for a `.php-packages` folder, fi=
rst in the current working directory then in parent directories.=C2=A0 If i=
t doesn&#39;t find one, business as usual.=C2=A0 If we do find one we follo=
w its directives about setting up an application environment.<br><br>The `.=
php-packages` folder is where PHP will put package related code for the app=
lication at hand.=C2=A0 Code written explicitly for these changes will also=
 put their package related files there - composer&#39;s vendor directory, c=
omposer.json, composer.lock, and so on - rather than putting those files in=
 the site root. The folder is hidden to prevent web servers like nginx or a=
pache from serving the files directly in any way.<br></div></blockquote><di=
v><br></div><div>First, you use the term Application=C2=A0then Site - decid=
e.</div><div>Not all PHP applications are HTTP Applications, consider consu=
mers, cron tasks other daemons, these don&#39;t need the existence of eithe=
r Nginx or Apache.</div><div>Not all PHP HTTP Applications expose files to =
Nginx or Apache - most of these I know like Rest API give ZERO access to an=
y application file to Nginx or Apache.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The .php-packages dire=
ctory will have a configuration file called `php.mod`.=C2=A0 This tells the=
 parser:<br></div></blockquote><div><br></div><div>You propose to move `com=
poser.json`, `composer.lock`, and `vendor` into a hidden folder with no goo=
d reason which simply adds more confusion.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Let&#39;s look at =
what such a file might look like for Drupal. For the moment I&#39;m going t=
o use go.mod&#39;s syntax. The final syntax to be used, be it ini, yaml, to=
ml, json, is a discussion for another time. The part to focus in on here is=
 what type of information do we need.<br><br><font face=3D"monospace">=C2=
=A0 package Drupal<br><br>=C2=A0 php 10<br><br>=C2=A0 registry //<a href=3D=
"http://packagist.org/packages" target=3D"_blank">packagist.org/packages</a=
> composer<br><br>=C2=A0 init (<br>=C2=A0 =C2=A0 composer install<br>=C2=A0=
 )<br><br>=C2=A0 require (<br>=C2=A0 =C2=A0 ./vendor/autoload.php<br>=C2=A0=
 )<br><br>=C2=A0 imports (<br>=C2=A0 =C2=A0 //<a href=3D"http://getcomposer=
.org/composer.phar" target=3D"_blank">getcomposer.org/composer.phar</a><br>=
=C2=A0 )<br></font></div></blockquote><div><br></div><div>This looks like a=
 completely new file format which simply makes interoperability harder, con=
sider tools like GitHub Dependabot, PHPMetrics or other tools that analyze =
dependencies - what you propose requires implementing a parser in userland =
or other languages the tool uses.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">The directives do the fol=
lowing:<br>...=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr">* init is the command(s) to run before the a=
pplication is started for the first time.<br></div></blockquote><div><br></=
div><div>What is the use case=C2=A0for it I don&#39;t get it.</div><div>Man=
y PHP Applications are distributed as a container image with all dependenci=
es already included.</div><div>How would it work with multi-threaded enviro=
nments, which thread would be responsible for running init? How do you solv=
e concurrency problems then?</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">If this theoretical version of D=
rupal moves its composer.json and composer.lock files into `.php-packages` =
then the autoloader doesn&#39;t have to be required in the index.php file.=
=C2=A0 Also, the application can be started without running `composer insta=
ll`<br></div></blockquote><div><br></div><div>`index.php` is just a common =
name for PHP HTTP Applications for modern frameworks like Symfony and other=
s that one lays in `public/` folder as an entry point, often this is the on=
ly file in this directory.</div><div>If I understand your idea correctly yo=
u&#39;d like a couple of I/O operations on the filesystem to find the `.php=
-packages` directory in CWD else if not in the parent directory and so on r=
ather than directly pointing where it is, right?</div><div><br></div><div><=
br></div><div>Cheers,</div><div>Micha=C5=82 Marcin Brzuchalski</div></div><=
/div>

--000000000000ac1351061c28ee35--