\Magento\Framework\Module\PackageInfo assumes locations

[apiuser]

Feature request from fooman, posted on GitHub Feb 14, 2016

This code

private function load()
{
    if ($this->packageModuleMap === null) {
        $jsonData = $this->reader->getComposerJsonFiles()->toArray();
        foreach ($this->componentRegistrar->getPaths(ComponentRegistrar::MODULE) as $moduleName => $moduleDir) {
            $key = $moduleDir . '/composer.json';

assumes that the registered path also holds the composer.json file which is not necessarily the case (for example https://github.com/fooman/sameorderinvoicenumber-m2/tree/v2.0.2/src). I am hoping there is a way to query composer itself for all packages of type magento2-module.

[apiuser]

Comment from davidverholen, posted on GitHub Feb 14, 2016

I'm not sure if you can query a composer instance for these paths, but it would be pretty easy to find them.

Since the composer.json is always in the root directory of the package, it just has to go to the parent dir until it finds the composer.json.

This could be limited to the vendor dir, so that it does not go any higher in the directory structure. The vendor-dir can be read from the root composer.json (default: vendor)

[apiuser]

Comment from fooman, posted on GitHub Feb 14, 2016

I think the underlying problem is that Magento has an internal name for a module which is defined via registration.php. This definition is not formally tied to the composer name (it usually follows the convention VendorName_ModuleName), however for their own modules they employ some trickery here https://github.com/fooman/magento2/blob/1535766cb5d9146485793462c9cc9270c970cf0e/lib/internal/Magent....

Just trialling something here https://github.com/magento/magento2/compare/develop...fooman:component-manager-reader-improvements?e..., where at least the parent dir is checked. It works but it's not quite right as this currently determines the name from the autoload section, and I think it would be better if it would get back the module name from the reader.

[apiuser]

Comment from davidverholen, posted on GitHub Feb 15, 2016

but, to read the module name from the composer.json, it would have first to know, where it is. Currently, there is no direct connection between the registered component and a module.

Searching it in the parent dirs would work but also is not really nice.

It would be possible to create a map in the magento-composer-installer: composer-name to magento module name.

The it would be easy to find the composer.json

[apiuser]

Comment from fooman, posted on GitHub Feb 15, 2016

but, to read the module name from the composer.json, it would have first to know, where it is.

That is what Magento currently tries to do, even though the composer.json name does not include the module name as it is known to Magento under.

Currently, there is no direct connection between the registered component and a module.

This is the overall process of how I currently have it pieced together:

1.) Magento application gets started 2.) includes Composer autoload information 3.) Composer autoload files includes modules' registration.php files 4.) registration.php file registers module with the framework (\Magento\Framework\Component\ComponentRegistrar), information includes directory and chosen name (Vendor_ModuleName) 5.) When PackageInfo is called (from the Component Manager for example) it retrieves all modules and their registered directory. I then searches for a composer.json file in that folder. 6.) From that composer.json it will then reconstruct the module name and in addition also reads in the require, version and conflict section.

Overall there are a few things to note - between step 3.) and 4.) there is a disconnect between composer and Magento which in step 5 is brought back together based on the assumption that the location registered via registration.php also holds the composer.json file.

I have attached a screenshot with a problem of the current approach:

I am currently thinking to make the ComponentRegistrar smarter by optionally allowing to register the composer name. And we could then query composer.lock for everything PackageInfo is looking for. Unfortunately there are also components which will never have a composer name so this needs to somehow be worked into it as well.

[apiuser]

Comment from buskamuza, posted on GitHub Mar 08, 2016

Internal ticket MAGETWO-49459