GithubHelp home page GithubHelp logo

installers's Introduction

A Multi-Framework Composer Library Installer

Continuous Integration

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 People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

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 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...

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?

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.

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?

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.

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.

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.

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.

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.