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 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. The largest block to composer's inclusion in Wordpress is the inability to run multiple versions of a module. Yes, it's a mess when this happens, but if you're an end user, you just want your plugins to work. If one plugin that no one has updated in a year that you're using is consuming version 2 of a package, you're gonna be annoyed at best if the module stops working when you install a new plugin that is using version 3 of the same package and has a BC break in it. Composer can't resolve this easily. There are WordPress plugins that use composer - I have a couple in the website I'm working on. But they accomplish the inclusion of composer by redistributing the packages, and using a utility called brianhenryie/strauss to monkey type the entire included package into the plugin, changing the namespace of the entire package to something different. The approach works, but it's ugly. In any event, the plugin that results from this carries a copy of the code from packagist rather than sourcing the code from packagist. -- IMPORT -- The import statement is for bringing in packages. It needs to be able to deal with: * Extensions - the existing and oldest of packages for PHP * PECL Extensions * Phar Packages * Composer Packages * PHP Modules - this is the new module system that has dominated the conversation, but in this iteration it's going to be broken away from import to some degree in this iteration. Today we'll look just at composer. Now import needs to load packages in a manner that allows different versions to be run concurrently. A PHP application such as Wordpress should be distributable without needing to use the command line. That is, if WordPress leverages this in any way, they don't have to give up their famous 10 minute quick install. Some terms here to keep myself from getting lost (let alone anyone trying to read this). * APPLICATION - This is the overall application - WordPress, Drupal, BobbysFirstFramework, etc. - that is doing the import. This code is on the root scope. * ROOT SCOPE - This is where the global variables and the namespaces as we know them exist. Contrast this with * 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. 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. So, GIVEN a package with this .php.mod file package MyModule WHEN I issue this import in an application import "MyModule"; THEN I should be able to access a method in that module with this code \MyModule\foo(); Aliasing is an option - `import "MyModule" as BeerModule` will make the methods accessible in the root with \BeerModule\foo(); Unlike require/include import is sensitive to the namespace it is in for mounting. So namespace Trees; import "MyModule"; MyModule\foo(); // works \Trees\MyModule\foo(); // needed from another namespace. That said, with aliasing an absolute namespace for the module can be assigned. namespace Trees; import "MyModule" as \MyModule; MyModule\foo(); // works if my understanding of existing namespace resolution rules is correct. \MyModule\foo(); // also works. Now, with that in place, let's crack a tougher nut - handling a composer package. By default composer is designed to set up an autoloader, then resolve symbol references as they come up. This works until you have two packages that want the same symbol reference - which will most frequently occur with incompatible versions of the same package. So our puzzle here is how to allow composer to do its thing without rewriting it. We'll deal with admittedly the hardest case first - importing a package whose maintainers have taken no action to make it compatible with this new system. import "composer://packagist.org/packages/twig/twig#v3.10.3" as TemplateEngine The reason for that alias and not "Twig" is because the mounting point comes before the internal namespace of the file. This is unavoidable with this scheme The URL there is "loader://package_url". PHP by default will know what the composer loader is. It will look to see if the user has globally installed composer already and use that, otherwise it will locally install composer for the project, initialize it, download the package and have composer resolve the package ending in setting up an autoloader that is only invoked within that package. Application configuration can make a lot of this go away. So let's step away from the import statement itself to look at that. -- APPLICATIONS -- Applications can configure how they store their packages, but in the absence of such PHP will use some logical default behaviors. We've already looked at one, the loading of a composer package, but we have a long ugly import as a result. Most PHP applications have a single point of entry, and part of that is the establishment of a cwd (current working directory). When PHP loads a file it will look for a `.php-packages` directory in the current working directory and if one doesn't exist it will make one the first time the import statement is invoked (so code not using import will not have this directory created). It is here that the package downloads land. We can also choose to go ahead and make this directory ourselves and place `.php.mod` in that directory. Let's look at what one might look like for Drupal, which already uses composer. package Drupal; php: 10 registry packagist.org/packages composer imports ( phar://getcomposer.org/composer.phar ) init ( composer install ) require ( ./vendor/autoload.php ) Now, composer is a known and popular quantity, so the imports, init and require directives can probably be baked into PHP, but if they ever change - or if a competitor to composer shows up like yarn did to npm then there needs to be a way to set it up. Also, for the moment I'm using go.mod's format because it feels the cleanest. The exact format of this file - whether it's yaml, json, toml, .ini or whatever else, is a discussion for another day. Key in on the type of information that needs to be relayed here, not how it's relayed. Importantly, because this .php.mod file is at the top level of the application's .php-packages directory it affects the behavior of the ROOT SCOPE. The php directive gives the minimum php version for the application. The registry directive sets the registry to packagist and sets the loader for that registry to composer. Multiple registries can have separate loaders. The imports directive loads composer using the default phar loader. We use an absolute path because we don't have a phar registry. This particular call could be baked in due to composer's popularity. The init directive runs the first time the application runs, just before any file in the application is parsed. The .php.sum file will bookmark the last time the init has run and there will likely need to be a mechanism to force it's rerun. The require directive requires these files once before starting the application's first file. Assume we move our existing composer.json file into .php-packages, what then? We gain the following: * Composer install will be ran for us, without using the cli. * The autoloader will be set up for us without explicitly requiring it anywhere. * We can install an alternate version of packages into their own package scope import "twig/twig#v2.5" as OldTwig; Or again, if we are in a namespace we can import to that namespace. I'll stop here cause this is a healthy chunk to absorb and I just spent 4 hours thinking on this as I wrote it out and I'm tired. If this was in the language today, Wordpress plugins could start using it without fear of mucking each other up or messing with Wordpress core. But that's a discussion for later.
