The lithium community uses the convention of naming our plugins/extentions li3*, when discussing the inclusion of composer we decided to adhere to this convention while using installer types for composer.

https://github.com/UnionOfRAD/lithium/issues/285#issuecomment-4347718

In August 2013 TYPO3 was added to composer/installers here as a first step for TYPO3's Composer support. However, as this was never sufficient for TYPO3 and never worked properly, the TYPO3 Core-Dev Team wrote its own installer and in February 2014 the first version was released. The two plug-ins, however, naturally clashed, and as more and more problems arose, a conflict was introduced on the TYPO3 side in November 2015. But as this caused new problems with packages relying on composer/installers, TYPO3 was removed again from composer/installers in January 2016.

As a result, a user complained and added TYPO3 again. But now we had a version of composer/installers without TYPO3 and we were able to relax our conflict definition a bit. Now it was possible to use our installer together with composer/installers and everyone was happy again.

Then came the release of Composer 2 a month ago and since there is no version compatible to v2 without TYPO3, the problem arised again. E.g. Aimeos and TYPO3 can't be installed with Composer 2 and Aimeos has opened an issue with us which we are not able to solve in our installer.

We currently see the following solutions:

1. Remove TYPO3 from composer/installers. Back in 2016 we were criticized that there was not enough time for a migration to TYPO3's installer. Now over 4 years have passed and this argument is or should be invalidated. But as we noticed back then, this is actually a breaking change and so you should actually publish a v2 of composer/installers after removing TYPO3 again, which is not very nice.
2. Introducing an event during the initialization of the installers as prepared in my PR. This would allow us to switch off the installer here for TYPO3 in our installer. Up to now, this has only been possible if our users deactivate the installer in their root composer.json via extra.installer-disable, which is an unreasonable demand and very error-prone. That's why I created this draft, which would allow disabling installers from within plugins. You have to tell me if this is desired from your side at all or maybe this contradicts your concept here.
3. Aimeos creates its own installer, either generally for all projects, they support not only TYPO3, or with a special installer for TYPO3 only.

In the opinion of the TYPO3 Core-Dev Team solution 1 would be the cleanest and the right one but we are open for a discussion here.

References:

• #96
• #281
• #300
• #466
• #469

CC:

• @bmack
• @naderman
• @EmiiKhaos
• @aimeos
• @mbrodala

This may be a better approach to what I was trying to achieve in my WordPress package pull request. Certain cases may be flexible and allow names/locations to be changed. This patch in my case for WordPress allows a custom content directory to be declared, as well as allows the composer root to live outside of the wordpress directory.

{
    "extra": {
        "package-paths": {
            "wordpress/wp-content/plugins/{$name}/": ["wordpress-plugin"],
            "wordpress/wp-content/themes/{$name}/": ["wordpress-theme"]
        }
    }
}

Can install all wordpress plugins and themes into the wordpress directory where the actual installation lives, opposed to maintaining an array of each of the package types in the install-paths array along side of the regular requirement declarations.

This time not limited to only wordpress.

Drupal core is to be installed to the project root. A "drupal-core" project would be: http://drupal.org/project/drupal

I have a fork of it using the "drupal-core" type at https://packagist.org/packages/robloach/drupal .

I am attempting to install on a Vagrant 2.2.4 VM running Ubuntu/bionic64 (Windows 10 Pro host machine). Other packages install fine, but this one returns "Plugin installation failed," attempts to roll back, and then fails to delete the contents of its installation directory.

Vagrantfile: https://pastebin.com/YQjAuPWL Composer.json https://pastebin.com/Tj1kMehb

vagrant@ubuntu-bionic:/home/app$ composer update -vvv
Reading ./composer.json
Loading config file ./composer.json
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Executing command (/home/app): git branch --no-color --no-abbrev -v
Executing command (/home/app): git describe --exact-match --tags
Executing command (/home/app): git log --pretty="%H" -n1 HEAD
Executing command (/home/app): hg branch
Executing command (/home/app): fossil branch list
Executing command (/home/app): fossil tag list
Executing command (/home/app): svn info --xml
Failed to initialize global composer: Composer could not find the config file: /home/vagrant/.config/composer/composer.json
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section
Reading /home/app/vendor/composer/installed.json
Running 1.8.6 (2019-06-11 15:03:05) with PHP 7.2.19-0ubuntu0.18.04.1 on Linux / 4.15.0-51-generic
Loading composer repositories with package information
Downloading https://asset-packagist.org/packages.json
Writing /home/vagrant/.cache/composer/repo/https---asset-packagist.org/packages.json into cache
Downloading https://repo.packagist.org/packages.json
Writing /home/vagrant/.cache/composer/repo/https---repo.packagist.org/packages.json into cache
Updating dependencies (including require-dev)
Reading /home/vagrant/.cache/composer/repo/https---asset-packagist.org/p-provider-latest-.json from cache
Reading /home/vagrant/.cache/composer/repo/https---asset-packagist.org/provider-bower-asset$jquery.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2013.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2014.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2015.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2016.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2017.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2018.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2018-07.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2018-10.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2019-01.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-2019-04.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-archived.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/p-provider-latest.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/provider-bower-asset$jquery.json from cache
Reading /home/vagrant/.cache/composer/repo/https---asset-packagist.org/provider-bower-asset$jqueryui.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/provider-bower-asset$jqueryui.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/provider-smarty$smarty.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/provider-oomphinc$composer-installers-extender.json from cache
Reading /home/vagrant/.cache/composer/repo/https---repo.packagist.org/provider-composer$installers.json from cache
Resolving dependencies through SAT
Looking at all rules.
Something's changed, looking at all rules again (pass #1)
Dependency resolution completed in 0.010 seconds
Analyzed 508 packages to resolve dependencies
Analyzed 2183 rules to resolve dependencies
Package operations: 2 installs, 0 updates, 0 removals
Installs: composer/installers:v1.6.0, oomphinc/composer-installers-extender:v1.1.1
  - Installing composer/installers (v1.6.0): Reading /home/vagrant/.cache/composer/files/composer/installers/9b12dbb8725af9a9ee8487c67b68262091bb71df.zip from cache
Loading from cache
 Extracting archiveExecuting command (CWD): unzip -qq  '/home/app/vendor/composer/installers/86ab17ee4b36addbac2f9c610c6203eb' -d '/home/app/vendor/composer/07959a72'
Plugin installation failed, rolling back
  - Removing composer/installers (v1.6.0)


  [RuntimeException]
  Could not delete /home/app/vendor/composer/installers/src/Composer:


Exception trace:
 () at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:217
 Composer\Util\Filesystem->unlink() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:170
 Composer\Util\Filesystem->removeDirectoryPhp() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:137
 Composer\Util\Filesystem->removeDirectory() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:238
 Composer\Downloader\FileDownloader->remove() at phar:///usr/local/bin/composer/src/Composer/Downloader/DownloadManager.php:299
 Composer\Downloader\DownloadManager->remove() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:224
 Composer\Installer\LibraryInstaller->removeCode() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:137
 Composer\Installer\LibraryInstaller->uninstall() at phar:///usr/local/bin/composer/src/Composer/Installer/PluginInstaller.php:66
 Composer\Installer\PluginInstaller->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:173
 Composer\Installer\InstallationManager->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:160
 Composer\Installer\InstallationManager->execute() at phar:///usr/local/bin/composer/src/Composer/Installer.php:595
 Composer\Installer->doInstall() at phar:///usr/local/bin/composer/src/Composer/Installer.php:229
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/UpdateCommand.php:163
 Composer\Command\UpdateCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:258
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:104
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:61
 require() at /usr/local/bin/composer:24

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

Adds support for the WordPress must use plugins directory (mu-plugins). This directory is for WordPress plugins that are automatically loaded. This new installer type is called wordpress-muplugin.

See http://codex.wordpress.org/Must_Use_Plugins for more information about this directory.

If we do a 2.0 release, we should make sure any installers which are not needed anymore get cleaned up. This will require a community effort though as we have no clue about most of the projects having custom installers here.

If you know of one which needs breaking changes or could be removed as it's unnecessary, please say so here. You can find the complete list in the README.

Already known/planned to be removed are:

• Pimcore
• TYPO3

Also noteworthy to most people reading this is that we are looking to improve even further the data available at runtime for users of Composer 2 (or 2.1+ in this case), which probably should help the use case of applications registering extensions dynamically at runtime: https://github.com/composer/composer/issues/9648

This adds the installer type concrete5-core to support the installation of concrete5 (version 5.7+) via Composer as discussed in https://github.com/concrete5/concrete5-5.7.0/issues/360.

The idea is similar to what Drupal is doing with drupal-core, but instead to core/ concrete5 is always installed to concrete/.

I will create a separate PR in the concrete5 repository to adjust the composer.json file.

For the upcoming CakePHP 3, the location of cakephp-plugin will be changed from Plugin to plugins.

This change enables this by overriding getLocations() and adjusting CakePHPInstaller::$locations according to the required cakephp/cakephp version.

In the getLocations() implementation, please let me know if there's a better way to get the required cakephp/cakephp Package object. And also, whether the version comparison code is correct/incorrect.

Also noticed that we never pass the Composer object when instantiating a new Installer object, so I add it in b072373.

I'm not sure if this is related to #10, but I feel it is different.

Currently installers determine that the name for a package (for example, the name for a CakePHP plugin) to simply be $prettyName. I feel that that may not always be the best name for a package.

For example, I have a this Git repo: https://github.com/uzyn/cakephp-aws-datasources. Its name at composer.json is uzyn/cakephp-aws-datasources. However, when it is installed as a CakePHP plugin, I would prefer it to be installed to Plugin/AwsDatasources instead of Plugin/CakephpAwsDatasources.

I could name my package uzyn/aws-datasources, but that would make it less obvious that it is a CakePHP-related package on both Packagist and GitHub.

There currently so many custom installers for different types of frameworks but Laminas is missing.

Laminas will normally install a "Module" into the root of an Laminas Application into module/.

In some Laminas module package you can use "type": "laminas-module"

Hi, I have successfully installed wordpress, defined in composer.json as package - pointing to a zip with a specific version.

As far as I know it is not possible to reference a Git(Hub) vcs type repository, without composer.json file. It could be done by providing missing metadata in my json file, therefore when upgrading, I would not need to edit the repository information (as is case with the package type).

Is there any different issue that would arise? I see that composer can already convert git tag to a version number. Thanks

Feature request: Some libraries are using versions as sub-paths (e.g. libraries/{$name}/{$version}), presumably to allow for multiple version support. If its easy to expose this as a variable, then this would save some code.

I use composer/installers as part of our roots/bedrock based WordPress multisite codebase. As part of a recent system update, we upgraded composer to version 2.3.5. After running normal deployment process, site was broken. Determined cause to be that WordPress theme and plugins had not been installed to custom locations, just installed into vendor folder. Downgrading to composer 2.1.3 fixed problem. We were running 2.1.3 locally, so that's why we tried that version; did not spend any time trying to identify specific version where defect occurs. Version of composer/installers in production is 1.12.

https://github.com/composer/installers/blob/main/src/Composer/Installers/Installer.php For example, how to output 159 lines of print($installpath),

I don't know how to debug