On Mon, Jul 1, 2024 at 1:33 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Michael,
>
> pon., 1 lip 2024 o 01:18 Michael Morris <tendo...@gmail.com> napisał(a):
>
>> ...
>> Applications
>>
>> The application is the 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, 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,
>

When you read my messages, I'll read yours. The fact that you blasted over
my statement of "The final syntax to be used is a discussion for another
time" betrays your intent - to torpedo this discussion and add nothing
valuable to it.

Reply via email to