composer / installers

A Multi-Framework Composer Library Installer

A Multi-Framework Composer Library Installer

This is for PHP package authors to require in their composer.json. It will install their package to the correct location based on the specified package type.

The goal of Installers is to be a simple package type to install path map. Users can also customize the install path per package and package authors can modify the package name upon installing.

Installers isn't intended on replacing all custom installers. If your package requires special installation handling then by all means, create a custom installer to handle it.

Natively Supported Frameworks:

Most frameworks these days natively work with Composer and will be installed to the default vendor directory. composer/installers is not needed to install packages with these frameworks.

Alternative to custom installers with Composer 2.1+

As of Composer 2.1, the Composer\InstalledVersions class has a getInstalledPackagesByType method which can let you figure out at runtime which plugins/modules/extensions are installed.

It is highly recommended to use that instead of building new custom installers if you are building a new application. This has the advantage of leaving all vendor code in the vendor directory, and not requiring custom installer code.

Current Supported Package Types

Stable types are marked as bold, this means that installation paths for those type will not be changed. Any adjustment for those types would require creation of brand new type that will cover required changes.

Framework	Types
Akaunting	akaunting-module
Asgard	asgard-module asgard-theme
Attogram	attogram-module
AGL	agl-module
Bonefish	bonefish-package
Botble	botble-plugin botble-theme
AnnotateCms	annotatecms-module annotatecms-component annotatecms-service
Bitrix	bitrix-module (deprecated) bitrix-component (deprecated) bitrix-theme (deprecated) bitrix-d7-module bitrix-d7-component bitrix-d7-template
CakePHP 2+	cakephp-plugin
Chef	chef-cookbook chef-role
CiviCrm	civicrm-ext
CCFramework	ccframework-ship ccframework-theme
Cockpit	cockpit-module
CodeIgniter	codeigniter-library codeigniter-third-party codeigniter-module
concrete5	concrete5-core concrete5-package concrete5-theme concrete5-block concrete5-update
ConcreteCMS	concretecms-core concretecms-package concretecms-theme concretecms-block concretecms-update
Croogo	croogo-plugin croogo-theme
Decibel	decibel-app
Dframe	dframe-module
DokuWiki	dokuwiki-plugin dokuwiki-template
Dolibarr	dolibarr-module
Drupal	drupal-core drupal-module drupal-theme drupal-library drupal-profile drupal-database-driver drupal-drush drupal-custom-theme drupal-custom-module drupal-custom-profile drupal-drupal-multisite drupal-console drupal-console-language drupal-config drupal-recipe
Elgg	elgg-plugin
Eliasis	eliasis-component eliasis-module eliasis-plugin eliasis-template
ExpressionEngine 3	ee3-addon ee3-theme
eZ Platform	ezplatform-assets ezplatform-meta-assets
ForkCMS ^v6.x	fork-cms-module fork-cms-theme
FuelPHP v1.x	fuel-module fuel-package fuel-theme
FuelPHP v2.x	fuelphp-component
Grav	grav-plugin grav-theme
Hurad	hurad-plugin hurad-theme
ImageCMS	imagecms-template imagecms-module imagecms-library
iTop	itop-extension
Kanboard	kanboard-plugin
Known	known-plugin known-theme known-console
KodiCMS	kodicms-plugin kodicms-media
Kohana	kohana-module
Lan Management System	lms-plugin lms-template lms-document-template lms-userpanel-module
Laravel	laravel-library
Lavalite	lavalite-theme lavalite-package
Lithium	lithium-library lithium-source
Magento	magento-library magento-skin magento-theme
majima	majima-plugin
Mako	mako-package
MantisBT	mantisbt-plugin
Matomo	matomo-plugin
Mautic	mautic-core mautic-plugin mautic-theme
Maya	maya-module
MODX	modx-extra
MODX Evo	modxevo-snippet modxevo-plugin modxevo-module modxevo-template modxevo-lib
MediaWiki	mediawiki-extension
Miaoxing	miaoxing-plugin
October	october-module october-plugin october-theme
OntoWiki	ontowiki-extension ontowiki-theme ontowiki-translation
OXID	oxid-module oxid-theme oxid-out
Osclass	osclass-plugin osclass-theme osclass-language
MODULEWork	modulework-module
Moodle	moodle-* (Please check source for all supported types)
Pantheon	quicksilver-script quicksilver-module
Piwik	piwik-plugin
Phifty	phifty-bundle phifty-framework phifty-library
phpBB	phpbb-extension phpbb-style phpbb-language
Plentymarkets	plentymarkets-plugin
PPI	ppi-module
Prestashop	prestashop-module prestashop-theme
Puppet	puppet-module
Porto	porto-container
ProcessWire	processwire-module
RadPHP	radphp-bundle
REDAXO	redaxo-addon
REDAXO bestyle-plugin	redaxo-bestyle-plugin
REDAXO V5.*	redaxo5-addon
REDAXO V5.* bestyle-plugin	redaxo5-bestyle-plugin
ReIndex	reindex-plugin reindex-theme
Roundcube	roundcube-plugin
shopware	shopware-backend-plugin shopware-core-plugin shopware-frontend-plugin shopware-theme shopware-plugin shopware-frontend-theme
SilverStripe	silverstripe-module silverstripe-theme
SiteDirect	sitedirect-module sitedirect-plugin
SMF	smf-module smf-theme
Starbug	starbug-module starbug-theme starbug-custom-module starbug-custom-theme
SyDES	sydes-module sydes-theme
Sylius	sylius-theme
TAO	tao-extension
TastyIgniter	tastyigniter-module tastyigniter-extension tastyigniter-theme
Tusk	tusk-task tusk-command tusk-asset
UserFrosting	userfrosting-sprinkle
Vanilla	vanilla-plugin vanilla-theme
Vgmcp	vgmcp-bundle vgmcp-theme
WHMCS	whmcs-addons whmcs-fraud whmcs-gateways whmcs-notifications whmcs-registrars whmcs-reports whmcs-security whmcs-servers whmcs-social whmcs-support whmcs-templates whmcs-includes
Winter CMS	winter-module winter-plugin winter-theme
Wolf CMS	wolfcms-plugin
WordPress	wordpress-plugin wordpress-theme wordpress-muplugin wordpress-dropin
YAWIK	yawik-module
Zend	zend-library zend-extra zend-module
Zikula	zikula-module zikula-theme

Example composer.json File

This is an example for a CakePHP plugin. The only important parts to set in your composer.json file are "type": "cakephp-plugin" which describes what your package is and "require": { "composer/installers": "~1.0" } which tells composer to load the custom installers.

{
    "name": "you/ftp",
    "type": "cakephp-plugin",
    "require": {
        "composer/installers": "~1.0"
    }
}

This would install your package to the Plugin/Ftp/ folder of a CakePHP app when a user runs php composer.phar install.

So submit your packages to packagist.org!

Custom Install Paths

If you are requiring a package which has one of the supported types you can override the install path with the following extra in your composer.json:

{
    "extra": {
        "installer-paths": {
            "your/custom/path/{$name}/": ["shama/ftp", "vendor/package"]
        }
    }
}

You can determine a non-standard installation path for all packages of a particular type with the type: prefix. The type must be one of types listed on the supported list above.

{
    "extra": {
        "installer-paths": {
            "your/custom/path/{$name}/": ["type:wordpress-plugin"]
        }
    }
}

You can also install all packages by a particular vendor to a custom installation path by using the vendor: prefix. The path will still only apply to packages by the vendor with a type in the supported list.

{
    "extra": {
        "installer-paths": {
            "your/custom/path/{$name}/": ["vendor:my_organization"]
        }
    }
}

These would use your custom path for each of the matching packages. The available variables to use in your paths are: {$name}, {$vendor}, {$type}.

Note: If multiple custom installer-paths match for the same package, the first one which matches will be used.

Custom Install Names

If you're a package author and need your package to be named differently when installed consider using the installer-name extra.

For example you have a package named shama/cakephp-ftp with the type cakephp-plugin. Installing with composer/installers would install to the path Plugin/CakephpFtp. Due to the strict naming conventions, you as a package author actually need the package to be named and installed to Plugin/Ftp. Using the following config within your package composer.json will allow this:

{
    "name": "shama/cakephp-ftp",
    "type": "cakephp-plugin",
    "extra": {
        "installer-name": "Ftp"
    }
}

Please note the name entered into installer-name will be the final and will not be inflected.

Disabling installers

There may be time when you want to disable one or more installers from composer/installers. For example, if you are managing a package or project that uses a framework specific installer that conflicts with composer/installers but also have a dependency on a package that depends on composer/installers.

Installers can be disabled for your project by specifying the extra installer-disable property. If set to true, "all", or "*" all installers will be disabled.

{
    "extra": {
        "installer-disable": true
    }
}

Otherwise a single installer or an array of installers may be specified.

{
    "extra": {
        "installer-disable": [
            "cakephp",
            "drupal"
        ]
    }
}

Note: Using a global disable value (true, "all", or "*") will take precedence over individual installer names if used in an array. The example below will disable all installers.

{
    "extra": {
        "installer-disable": [
          "drupal",
          "all"
        ]
    }
}

Should we allow dynamic package types or paths? No

What are they? The ability for a package author to determine where a package will be installed either through setting the path directly in their composer.json or through a dynamic package type: "type": "framework-install-here".

It has been proposed many times. Even implemented once early on and then removed. Installers won't do this because it would allow a single package author to wipe out entire folders without the user's consent. That user would then come here to yell at us.

Anyone still wanting this capability should consider requiring https://github.com/oomphinc/composer-installers-extender.

installers's Issues

Composer Installers "reserves" package types it specifically intends to never use

I built a WordPress Core installer to handle installing WordPress core as a package outside the vendor directory. It tries to use the wordpress-core package type, but it's running into issues when used together with the installers package because of how the BaseInstaller handles unrecognized types. It's already been established that core types are out of the scope of Installers (e.g. #77 ) and the correct approach is to build my own installer, but the current behavior of composer installers prevents me from using the package type that makes sense for my installer.

Installers should only concern itself with the types it supports and should get out of the way for all other types.

Prefix vendor-dir if defined in user's composer.json to paths

Ref #148.

Given the following composer.json:

{
    "repositories": [
        { "type": "git", "url": "https://github.com/Mihailoff/installer-test.git" }
    ],
    "require": {
        "mihailoff/installer-test": "0.1.0"
    },
    "config": {
        "vendor-dir": "custom"
    }
}

installer-test should be installed into custom/blocks/installer-test but currently it is installed into blocks/installer-test.

Process installer type in declared repositories

Suppose there is such config

{
       "repositories": [
        {
            "type": "package",
            "package": {
                "name": "vendor/foo",
                "version": "2.6",
                // DEFINE INSTALLER TYPE //
                "type": "some-plugin",
                "require": {
                    "composer/installers": "~1.0"
                },
                // --- //
                "dist": {
                    "url": "http://download.org/package.zip",
                    "type": "zip"
                },
            }
        }
    ],
    "require": {
        "vendor/foo": "2.6"
    }
}

Expected result is to get installed vendor/foo as some-plugin.
Actual result is that it installs like ordinary package in vendor directory.
I have no access to given package and can't create composer.json there.

Add extra to disable installers

Setting this extra would disable installers and install to the native vendor dir. Useful for users who have configured their framework to consume packages from the default dir (but the framework has not officially supported it).

Reference this topic: https://groups.google.com/forum/?fromgroups=#!topic/composer-dev/9JtvlkQ1DNE

Maybe installer-disable?

Add repository WP plugins/themes/mu-plugins from GitHub

Hello everyone,

I am a little lost on how to add WP plugins/themes/mu-plugins hosted on GitHub as a new repository. My composer.json file defines repository this way:

{
  "type": "package",
  "package": {
    "name": "wpgrouse/grouse",
    "version": "0.1.0",
    "type": "wordpress-theme",
    "source": {
      "type": "svn",
      "url": "https://github.com/wpgrouse/grouse"
    },
    "require" : {
        "wordpress/wordpress": "3.9"
    }
  }
},

... which throws this exception: A repository of type "package" contains an invalid package definition [...] .

I suppose the problem lies within the souce block as documentation provides reference parameter which I don't quite understand.

Thanks in advance!

installer-paths bug

Not too sure if it's a bug, or there's something wrong in my config.

My root composer.json:

{
    "require": {
        "uzyn/cakephp-opauth": "dev-composer"
    },
    "minimum-stability": "dev"
}

composer.json for uzyn/cakephp-opauth under dev-composer branch included this:

    "extra": {
        "installer-paths": {
            "Plugin/Opauth/": ["uzyn/cakephp-opauth"]
        }
    }

After running composer install, package gets installed to Plugin/CakephpOpauth/ instead of the expected Plugin/Opauth/

How can I test a new installer locally

Hi,

I am trying to create a custom installer, following patches like puppet and roundcube as all I need is to copy certain directories to specific places in the application structure.

I made the changes and now I would like to test it before submitting the pull request but I don't know how.

I tried directly appling the changes to the Installers src directory after downloading and deleting my module's content but after "composer update" the code ends up inside the vendors directory again so I don't know if I did something wrong or that is not the way to test it.

Thanks for any help.

Lib without Packagist + composer/Installers dont work

My composer.json:

{
    "repositories":{
        "cakephp-unofficial":{
            "type": "cakephp-plugin",
            "package": {
                "name": "pronique/CakePHP-Sluggable-Behavior",
                "version": "1.0",
                "source": {
                    "url": "git://github.com/pronique/CakePHP-Sluggable-Behavior.git",
                    "type": "git",
                    "reference": "origin/master"
                }
            }
        }
    },
    "require": {
        "php": ">=5.3",
        "composer/installer": "*",
        "pronique/CakePHP-Sluggable-Behavior": "*"
    }
}

Then:

-> % composer install --dev
Repository type is not registered: cakephp-plugin

Drupal Site

In a Drupal Multi-Site environment. It would be really helpful if Composer Installers supported installing a Drupal Site. This would allow site administrators to manage each site in a different repository like davidbarratt/davidwbarratt. This would allow the admin to have each site separate from the Drupal install itself and use Composer to manage the sites across different environments (staging, dev, local, etc.).

It would also allow the site itself to define PHP/Drupal dependencies. (i.e. the site can list out all of the libraries, modules, themes, etc. that the site requires to operate). You could even use this in a single-site setup by just pointing the site to the "default" folder.

Not only would this be helpful to Drupal admins, it's a minimal change for Composer Installers.

Thanks!

Consider new types for DrupalInstaller?

//cc @grayside @RobLoach

Just a meta-issue -- not really actionable yet. Just for your consideration:

Currently Baton supports module and theme types, but here are the types that Drush uses: http://drupalcode.org/project/drush.git/blob/HEAD:/docs/make.txt#l110

I know you probably don't want to get into the tedium of drupal-narnia, but there's a CLI tool called Drush that we use, and it has a make command that converts a file manifest into a working website layout.

Some people are thinking that Composer could someday be used to drive some parts of Drush (and Drush Make). I think the thought is that Baton might be able to help with some of that logic.

Just to give some context, that is :)

Commit Dependencies in my Plugin Directory

This picks up from option 4 here:
https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

i'm using the installer with CakePHP and therefore the packages will be within the Plugin folder.

i've tried to add the following to git ignore so that i can commit plugins to the master project (i know this is frowned upon by most of the composer community, but in my situation it is the best option):

Plugin/.git
Plugin/**/.git

But, alas, git still treats these as submodules and will not commit them to the master project.

Are plugin "submodules" being tracked within the installer somehow? I'm completely stumped...

Automatically Determine Install Path

Most, if not all, install locations could be automatically discovered rather than hard coded into Baton.

Support For Symfony 2.0

Reference: https://twitter.com/seldaek/status/214995304792068096
Unfortunately my experience with Symfony is limited. I assumed it worked out of the box because of the vendor folder. Could someone point out the desired install paths for Symfony 2.0?

Add extension- or plug-in mechanism to register new installer types

It would be nice to write additional (may be proprietary) installers, that can reuse the existing functionality of this project.
Wouldn't it be nice to add installers just by writing a new class that extends the BaseInstaller and defines the $locations array without the need to modify Composer\Installers\Installer::$supported types?

extend $locations

Hello, is there an easy way to extend these locations?

https://github.com/composer/installers/blob/master/src/Composer/Installers/CodeIgniterInstaller.php

I would like to add widget, shared-addon paths...

Thank you!

PHP Composer Library Installer did not install any plugin

I already posted a question here: http://stackoverflow.com/questions/16603879/php-composer-library-installer-did-not-install-any-plugin

Basically I want to ask did I miss something?

Missing Frameworks

More PHP frameworks that should be included (in no particular order):

• Magento 29a5ba9
• Yii 85e4442
• Solar/Aura See #24
• Zikula
• PPI c50ae51
• Agavi
• Chisimba
• ezPublish
• Phorum
• MicroMVC
• Kohana 59bb85073c92d77c07112188726546e3958d16d0
• TYPO3 a02480a
• FLOW3

Actual Package Install Tests

Probably a good idea to pick or create actual packages to install, update and remove in the test suite. The current tests just double check the results but don't actually do any installing.

Bug triggered by simple name of package

If I create custom pacage from git for exaple. And give name like "name": "sfPhpunitPlugin" it throw nitice in Composer\Installers\BaseInstaller

If I give name like "name": "plugin/sfPhpunitPlugin" it works fine but you should display specific message or add support for simple name.

Add wordpress-core type

WP extensions are already finely supported by installers, but the situation with WP core itself is less smooth. If it is placed in root then it's not subject to Composer, however subdirectory installs (which only recently became supported for all cases) are and probably should be.

However typical subdirectory install for WP is not the same thing as for typical Composer library, because paths matter, are exposed in admin area URLs, etc. In a nutshell putting WordPress core into vendor directory would be atypical and possibly problematic (technically and/or to satisfy requirements of specific projects).

Currently working options:

1. Declare core to be of wordpress-plugin installer type and customize installer path for it to wordpress (or other desirable path with single level of nesting). Confusingly puts core into plugins directory, if path is not customized.
2. Declare core to be of fake wordpress-core type. More logically goes into vendor if path is not customized, but non-existent type feels like a hack, I am not sure won't stop working.

Proposal:

Add wordpress-core type with default wordpress path for valid subdirectory install by default without path customization.

how to have same library class file but packaged for multiple frameworks?

This is more of a question than an actual issue I found with composer installers.

Suppose I write my own utility class, say a NumberFormat class.

I want to be able to use it easily as a Symfony component AND a CakePHP plugin.

Of course, I can simply have two separate repositories and each composer.json would naturally have a different type.

But that would mean I have the same code written twice.

Is there a DRY way to expose same library class to multiple frameworks to install?

Remove "default" from supported types

I don't see the need for a default subtype. Package authors should write full type explicitly.

Unable to install with Composer

Just did a composer self-update and I get the following exception:

[RuntimeException]
Plugin composer/installers is missing a require statement for a version of the composer-plugin-api package.

Composer version 242c58c789cb6505d12593b8258625e5f83bba0c

Yii native support

Hi, can you please describe how Yii is natively supported?

I know it had support in 1.0.3 version, but this is not true with next version.

When I browse through issues #68, #71 and #75 i see it was removed finally.

So native suport means I have to manage it own way, right?

Thanks!

Joomla

How is the Joomla component envisioned to work? IE is this to install code into an existing Joomla website or for something else?

Primarily I ask because if it is for a Joomla website then there is some missing items: for Joomla Components there are typically 2 directories which contain component code. For example, for MyComponent
administrator/components/com_mycomponent
components/com_mycomponent

Configuration code goes under the admin root, end user code under the main root.

Not the end of the world and easily modified, I'm just curious to know how it is envisioned that this would be used?

Custom Install Type (Like Names)

I was thinking about #178, and I realized that perhaps we're going about this all wrong.

What if Composer Installers recognized custom types? I understand that a package author is not allowed to do this, for good reason. But what if a consumer is allowed to?

We already have the ability to define Custom Install Names. Perhaps it's not too far of a leap for Composer Installers to accept Install Names of types that it does not recognize itself?

For instance, if I put this in the project's root composer.json file:

"extra": {
  "installer-paths": {
    "web/sites/{$name}/": ["type:drupal-site"]
  }
}

Composer Installers obviously wouldn't understand what to do with drupal-site.... but aren't I telling it what to do? I'm telling it to put it in web/sites/{$name}/.

Doing this would allow people to manage custom project types in a "safe" way (i.e they are not at the whim of the project author). It also prevents having to have to define what should or should not be included into Composer Installers. Actually, I could make a case for not having Composer Installers understand any types at all, but that's probably pushing it. :)

I think this would solve a lot of people's problem. Honestly, I tried this to see if it would work before I proposed #178. I think this would be the best solution for everyone.

Possibility to prefix installation path

It would be very helpful if the installation path could be prefixed. The installation path can be overwritten via composer.json [extras -> installer-paths], but this has to be done for every package or package type.
A prefix of the install path would solve this issue. A possible use case of this feature is the following:
With the help of Webroot Composer Library Installer Wordpress could be installed in a subfolder like web. If we include a Wordpress-Plugin in the same composer.json without a declaration of 'installer-paths' the plugin will be installed at wp-content/plugins/{$name}/. The correct path would be web/wp-content/plugins/{$name}/.
With the support of prefix this could be solved easily.

{
    "extra": {
        "installer-paths-prefix": "web"
    }
}

This can be extended even further:

{
    "extra": {
        "installer-paths-prefix": {
          "package-folder": ["vendor/package"],
          "type-folder": ["type:wordpress-plugin"],
          "framework-folder": ["framework:wordpress"]
        }
    }
}

Let me know what you think about this proposal. I might find the time to do a PR.

Create tag v1.0.7

The last release was 3 months ago.

Support for concrete5 has been added since: v1.0.6...master

Missing a require statement for a version of the composer-plugin-api package.

[RuntimeException]
Plugin composer/installers is missing a require statement for a version of the composer-plugin-api package.

Remove YiiInstaller

I am sorry that I have to create this issue, but please remove the YiiInstaller from composer/installers.

As discussed on composer-dev and Yii issues there are no specifications for Yii 1.x applications how they have to be structured and the current installer might break existing composer-based Yii applications.

Drupal location needs love

https://github.com/shama/baton/blob/master/src/Baton/DrupalInstaller.php#L10
Just found this project and a quick heads up:

drupal expects for TYPE modules/themes/libraries to be in sites/all/TYPE/{name} by default, but sometimes (for a multi-site install), needs modules installed in, say, sites/example.com/TYPE/{name}

For now, even changing modules/{name} to sites/all/modules/[name] etc would be a huge improvement, as only core themes/modules should be placed in the directory that's specified now :)

Will look into submitting a pull request after work

Installer class in programmatic use

Hi,

i am playing around with Composer and trying to use it embedded in an WordPress environment. For me it makes not much sense to use the Installers as requirement in a WP Plugin package i also don't think some deployment directory path change for a package should result in a dependency requirement.

Anyway, i think there might be a problem in Installer.php

public function uninstall(InstalledRepositoryInterface $repo, PackageInterface $package)
    {
        $installPath = $this->getInstallPath($package);
        $this->io->write(sprintf('Deleting %s - %s', $installPath, $this->filesystem->removeDirectory($installPath) ? '<comment>deleted</comment>' : '<error>not deleted</error>'));
    }

In my setup the Installer is programmatically added to the InstallationManager. So i am not sure, if this will be reproducible in normal use, but behaviour now is, that after uninstalling a package it is still present in the local repo json, due to the missing line

$repo->removePackage($package);

Let me know if i can do something...
Best Regards

Simplify BaseInstaller::templatePath() with eval()...

Please forgive this totally oddball question. I just stumbled upon the project today and reviewed the code. I occasionally know what I'm talking about. Occasionally.

In BaseInstaller::templatePath(), it seems like rather than reinventing the PHP parser with regex patterns, it might be simpler to execute eval() on the templated path. I know, I know, eval() == evil, but this usage is precisely what it's for. Consider:

if ( strpos($path, '{') === false ) return $path;

extract($vars);

return eval('return "' . $path . '";');

No looping necessary, just variable replacement via the interpreter, the way Rasmus intended. Could be shortened further with a ternary, but why confuse matters...? A nice comment on the line could go far to explain the voodoo.

I have braced for stones and tomatoes.

Are packages uninstalled, when dependency is removed?

Hi,
today I've noticed, that packages installed in custom way (via composer/installers) are not deleted after removing dependency in composer.json. Composer writes "Removing SOME/PACKAGE (VERSION)" but package is not deleted physically. For me, it is huge problem. My packages installed via installers have other dependencies (normal packages) and when their dependencies are deleted, then my package breaks whole webapp.

Please define a tag on the current version

Hi,

Please define a tag on the current version.

Thanks :)

Folders of custom path are not created

Hi,

I am trying to install dependencies using either a recognized type or some pseudo type with the following definition :

{
  "extra" : {
    "installer-paths" : {
      "application/modules/{$vendor}/{$name}/": ["type:maell-module"]
    }
}

Unfortunately, it looks like the folders are not automatically created as should be expected and I end up with an UnexpectedValueException exception from RecursiveDirectoryIterator::__construct().

Am I doing something wrong ?

Using Composer/Composer Installers in CakePHP app

This is not an issue of Composer Installers per se. More to do with the use of Composer/Composer installers in a CakePHP app.

Elaboration below:

I am having some weird issues with git submodule update for a Plugin dependency with Jenkins @ CloudBees.

So I am switching some, if not, all my dependencies from git submodule to Composer.

I came across this repo called composer installers. https://github.com/composer/installers

I was wondering how to use this for both Plugin and Vendor dependencies.

I am not familiar with Composer and even after reading the docs, I am uncertain how to say, place this dependency specifically to Plugin/xxx

I know how to do this with git submodule add.

So how do I do the same but with Composer or better yet, Composer installers, please advise me.

To make things easier, I want to use 2 actual examples.

• https://github.com/milesj/Utility is to be placed inside my app/Plugin/Utility
• https://github.com/simkimsia/php-gd-simpleimage is to be placed inside my app/Vendor/SimpleImage

Add support for type:drupal-site

In our environment, each site directory will be a composer package. It would be nice if this would be supported by adding a "drupal-site" type which would place the package in question under sites/{$name}

Auto-Detect Drupal Single Site Install Path

Reference #42, #36 and #15. The Drupal types currently require the composer.json to be located in the sites/all folder to allow for multi-sites. It appears to be common to want to locate the composer.json in the root of a drupal app. So would be nice for the DrupalInstaller to detect whether it's in root of the app to prefix sites/all/ to the install path.

@RobLoach has done this in his DrupalInstaller. I think the detection stuff makes sense (and would love a PR or your copy permission Rob) but I would like to get #43 done first.

This would make it so core drupal modules and themes cannot be installed with composer/installers. Which is a good thing but just making it clear.

Adjust var replacements

In the composer config, values can use other config values like this:

"{$vendor-dir}/bin" for example is the value for bin-dir. It might be good to use the same pattern in the installers (i.e. add the $) for consistency.

Allows for custom name that is different from package name?

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.

Allow per package installer-paths for unmanaged types (or add a special type)

There are times when it's necessary for a dependency to live outside of vendor/. For instance, projects such as WordPress want to live somewhere in the web/ folder.

A couple of requests to that order have occurred in the past, asking for wordpress-core or drupal-core or what not. As I understand it, they got closed owing to the fact that they're too localized, in the sense that only one package would ever use it. Which is fair enough.

The current options are to either write a custom installer to that order, or abuse composer/installers by making e.g. WordPress itself masquerade as a wordpress-plugin and configuring a custom installer-paths accordingly. The same for language files. This makes absolutely no sense...

Could we instead simply have composer/installers pick up the installer-paths directives for any package, including types it's not supposed to recognize?

Along the same lines, could we force it to recognize a type by merely encountering it in composer.json with an assorted installer-paths directive? This could be useful, for instance, in a scenario like:

{
  "name": "wordpress/core",
  "type": "wordpress-core",
… 
},
{
    "name": "wordpress/locale-fr
    "type": "wordpress-language",
…
},
…
"installer-paths": {
    "www/wp": [ "wordpress/core" ],
    "www/wp-content/language/{$name}": ["type:wordpress-language"]
}

If that is not an option, could we add a generic sounding type, e.g. web-package or custom-package or even custom that could be used by all of these projects?

CakePHP Plugin install path

The install path of a CakePHP plugin is Plugin/$name, and this would be correct if the composer.json is located within the /app/ directory.

What if the composer.json is located one level up? The plugin will not be installed into app/Plugin/$name nor in plugins/$name.

Proposed fix:

• Check the location of the composer.json and install in Plugin/$name or app/Plugin/$name accordingly

Since app can be named something else, it's probably easier to install the plugin inside the application-wide plugins/$name directory instead.

Native Extensions Installer

There was an initiative about a year ago to make composer able to compile and install native extensions (composer/composer#498), but I think its kind of dead at the moment.

I would really like this ability in composer (As it would work really well with travis-ci and presumably other CIs) but it seams the core team is unreceptive to the idea.

So I was wondering can composer/installers be used for such a task. I'm prepared to strike on my own and implement this, though I will not be able to test this under windows probably.

The question is "Is this actually possible under composer/installer (without windows support) or this is something that can only be implemented in the core? Does anyone have tips/suggestions for me?

composer install on project does not create autoload files for subpackage

I made a WP plugin as a composer package and tried to use the autoloader functionality by composer. This all works well if I do a composer install in the plugin directory because the autoloader files are created and I can require vendor/autoload.php just fine in my main plugin file.

 "autoload": {
    "psr-4": {"ExamplePlugin\\": "src/"}
}

But when I put this plugin as a package in a project composer file the plugin ends up in: web/app/plugins/example-plugin because of the installer-paths. That's great. Works perfectly.

But the autoloading files were not generated because composer only generates it for the main composer.json which means the plugin will be broken because none of the internal classes will be loaded correctly.

I hope I explained it well.

Add binary to get list of packages with their respective paths from command line

Hi,

I've used Composer + Installers for quite some time now. I am looking for a way to get the list of installed packages (including dependencies) with their respective installer paths.

I don't know if this is possible, but I was thinking something like this:

$ composer show --installed --path
composer/installers    /home/user/path/to/package    v1.0.12    A multi-framework Composer library installer 

If we can't use the core show binary then maybe something like this:

$ composer show-paths --installed
composer/installers    /home/user/path/to/package

Thank you

Add a generic `custom` or something type

One common request is to install packages in a custom dir. Now this package allows this for common patterns of various frameworks, that's cool. But I think if we had a custom type that just enabled composer-installers handling without however specifying any path, it would at least allow people to register their own weird packages as type:whatever and then in their app package specify the install paths with extra.installer-paths.

I think it would alleviate the need for small shops with weird old setups to create a custom installer just to drop files in another folder.

Roll your own path feature

The "roll your own path" thing should really be removed from the package definition, and moved to the consumer side. I think something like this would make more sense:

{
    "extra": {
        "baton-paths": {
            "sites/example.org/modules/{name}": ["vendor/package", "vendor/package2"]
        }
    }
}

Although we could maybe just add that at the top level and add support for it in composer, that way people can define where they want their stuff installed, and the baton installers would respect this if present, otherwise fallback to default dir. I think it would fit well with the planned stuff for assets in composer/composer#524.

Stable version release

Are we able to have a stable version release soon due to https://groups.google.com/forum/#!topic/composer-dev/_g3ASeIFlrc/discussion ?

It's not very convenient to require user of an installer plugin to have "minimum-stability": "dev" all the time.

Thanks.

Type Compatibility Matrix

As a consumer, I would like to install libs from other frameworks. Currently if I install a lib from another framework, installers would use the install path from the package. Being a consumer, it should use the path of my framework. A consumer could override their own path for each package with #10 but I think it would be friendly to translate the path if a compatible one exists.

For example, I'm a CakePHP user that wants to use a Laravel library. The package type is laravel-library and my consumer type is cakephp-app. Installers could determine a laravel-library type when installed to a cakephp- should use the cakephp-vendor type instead.

This of course would be succeeded by the any consumer set install path and is dependent on the ability for installers to access the consumer's config file.