search

oomphinc / composer-installers-extender

Extend the composer/installers plugin to accept any arbitrary package type.
MIT License
236 stars 52 forks source link

Have to run composer install twice to make custom installer paths work #6

Closed jfarthing84 closed 7 years ago

jfarthing84 commented 8 years ago

I hope this is not something just on my end. For some reason or another, I have to run composer install twice, in order to get packages to go where they are assigned in composer.json. That is, it has to be run once initially, and then it appears each subsequent run works as expected.

Also, after the initial composer install, all packages go to the vendor directory.

jfarthing84 commented 8 years ago

It's probably worth noting, that the packages are using custom types, as defined in the installer-types array in the project's composer.json:

{
    "config": {
        "preferred-install": "dist",
        "vendor-dir": "htdocs/vendor"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "git@bitbucket.org:jfarthing84/vanilla-theme.git"
        },
        {
            "type": "vcs",
            "url": "git@bitbucket.org:jfarthing84/vanilla-plugin.git"
        },
    ],
    "require": {
        "php": ">=5.5",
        "oomphinc/composer-installers-extender": "^1.1.1",
        "jfarthing84/vanilla-theme": "dev-master",
        "jfarthing84/vanilla-plugin": "dev-master"
    },
    "extra": {
        "installer-types": ["vanilla-plugin", "vanilla-theme"],
        "installer-paths": {
            "htdocs/web/app/plugins/{$name}/": ["type:vanilla-plugin"],
            "htdocs/web/app/themes/{$name}/": ["type:vanilla-theme"]
        }
    }
}
jfarthing84 commented 8 years ago

For reference, here's the theme's composer.json:

{
  "name": "jfarthing84/vanilla-theme",
  "description": "A theme for Vanilla.",
  "keywords": ["vanilla", "theme"],
  "license": "GPLv2",
  "authors": [
    {
      "name": "Jeff Farthing",
      "email": "jeff@jfarthing.com",
      "homepage": "https://jfarthing.com"
    }
  ],
  "type": "vanilla-theme",
  "extra": {
      "installer-name": "VanillaTheme"
  },
  "require": {
    "php": ">=5.3",
    "composer/installers": "^1.1"
  }
}

And here's the plugin's composer.json:

{
  "name": "jfarthing84/vanilla-plugin",
  "description": "A plugin for Vanilla.",
  "keywords": ["vanilla", "plugin"],
  "license": "GPLv2",
  "authors": [
    {
      "name": "Jeff Farthing",
      "email": "jeff@jfarthing.com",
      "homepage": "https://jfarthing.com"
    }
  ],
  "type": "vanilla-plugin",
  "extra": {
      "installer-name": "VanillaPlugin"
  },
  "require": {
    "php": ">=5.3",
    "composer/installers": "^1.1"
  }
}
balbuf commented 8 years ago

Hey Jeff! Thanks for providing all the details - I will try look into this soon. Could you also confirm what version of composer you're on?

jfarthing84 commented 8 years ago

Composer version 1.2.0 2016-07-19 01:28:52

jfarthing84 commented 8 years ago

To further clarify, I did some additional tests.

Starting out, the vendor directory doesn't exist. The first composer install puts all packages into the vendor directory. If I then remove the vendor directory and run composer install again, the same thing happens. However, if I leave the vendor directory and run composer install again, the packages end up where they are supposed to.

Also, just creating an empty vendor directory before the initial composer install makes no difference.

Does this plugin just copy the package from the vendor directory to the desired location? If so, that would halfway explain this...

balbuf commented 8 years ago

Hi Jeff - thanks for the additional information. I haven't had a chance to look into this yet but hopefully I will soon. The installer does not copy from vendor but instead installs directly to the destination(s) you configure in your composer.json file.

It would also be helpful for me to know if you have an global plugins at play. If you could provide me the output from composer global show -D that would be great. Thanks!

jfarthing84 commented 8 years ago 
$ composer global show -D
Changed current directory to /home/jeff/.config/composer
Composer could not find a composer.json file in /home/jeff/.config/composer
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section
balbuf commented 8 years ago

My first hunch has that there is another installer that is taking precedence over this plugin, but it appears you don't have any global plugins installed. Thanks for sending along the info regardless!

jfarthing84 commented 8 years ago

It is very important for me to get this working correctly ASAP - so anything I can do, let me know!

balbuf commented 8 years ago

If the intended effect is had after running composer install twice, while not "correct", shouldn't that work for you for now?

jfarthing84 commented 8 years ago

I suppose so...

jfarthing84 commented 8 years ago

Another observation: Delete composer.lock and run composer install and all packages go where expected. Delete all the packages that were just installed, keeping the composer.lock that was just generated, run composer install again and everything goes into vendor.

pascalek commented 8 years ago

This probably is related to the order composer installs packages. Try adding oomphinc/composer-installers-extender to the required section of packages you are installing. This solved it in my case.

jfarthing84 commented 8 years ago

I actually got composer/installers to merge my pull request to support Vanilla. So, I'm good now - though this is still a bug.

dwenzel commented 7 years ago

I can confirm this issue: Library packages are installed into vendor/<vendor name>/<package name>/ directory instead of <library path>/<package installer name> on first composer install. If I do a second composer install or composer update, packages are moved to the expected path. (some duplicates remain in the vendor path though).

If the package composer.json requires oomphinc/composer-installers-extender everything works fine on first install.

This is my working setup: Package composer.json

{
  "name": "fooVendorName/bar-legacy-userfunc",
  "description": "....",
  "type": "legacy-fileadmin-library",
  "require": {
    "oomphinc/composer-installers-extender": "^1.1"
  },
  "extra": {
      "installer-name": "userfunc"
  }
}

Main composer.json

{
  "name": "foo/bar",
  "description": "...",
  "config": {
    "vendor-dir": "app/vendor",
    "preferred-install": {
      "*": "dist"
    }
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "git@path-to-legacy-package/userfunc.git"
    }
  ],
  "require-dev": {
    "fooVendorName/bar-legacy-userfunc": "dev-develop"
  },
  "extra": {
    "installer-types": ["legacy-fileadmin-library"],
    "installer-paths": {
      "app/web/fileadmin/{$name}/": ["type:legacy-fileadmin-library"]
    }
  }
}

Package fooVendorName/bar-legacy-userfunc is being installed to app/web/fileadmin/userfunc

stefanruijsenaars commented 7 years ago

This probably is related to the order composer installs packages. Try adding oomphinc/composer-installers-extender to the required section of packages you are installing. This solved it in my case.

This fixed the issue for me (see https://github.com/openfed/openfed8-project/commit/aa2b773f60c5caa3b630c42ea644bc52becac38e)

Can we rename this issue to "Have to run composer install twice to make custom installer paths work" so it's more easily findable in the issue queue? And maybe make a note in the README as well?

daften commented 7 years ago

I'm having the same issue, putting this package in require doesn't help me.

phenaproxima commented 7 years ago

I have this problem as well! But I am not in control of the packages I'm requiring, so I can't add this to their required sections...not sure how to proceed with this.

landsman commented 7 years ago

I have same problem and I want requiring 3rd party packages like chosen. Is here some working solution?

balbuf commented 7 years ago

Hi everyone - I apologize that we have not been able to address this any sooner! I've done some digging through the composer's source and I believe I have a working solution.

TL;DR: move "oomphinc/composer-installers-extender" to the top of your require section, or at least before any packages that need to be installed to a custom path.

The explanation: Typically composer will move plugins to the front of the line when installing packages, as these plugins might affect how other packages are installed (e.g. custom installers); see: https://github.com/composer/composer/blob/master/src/Composer/Installer.php#L745. However, plugins that have dependencies other than composer-plugin-api are not moved. In the case of this plugin, it has composer/installers as a dependency and thus is not moved to the front. What this means is that other packages might be installed before composer-installer-extender is installed and run and thus are not installed to the correct location. On the second execution of composer install, composer-installer-extender is already installed and will correctly place the packages in their custom paths.

In my testing, this issue is avoided by putting "oomphinc/composer-installers-extender" as the first dependency in the require section, or at least before any other dependencies that will be installed to a custom path.

Consider these examples:

Example 1

{
    "name": "oomphinc/composer-test",
    "require": {
        "psr/log": "*",
        "oomphinc/composer-installers-extender": "*"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is installed to vendor/ instead of off-the-beaten-path/

Example 2

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "*",
        "psr/log": "*"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/

Example 3

{
    "name": "oomphinc/composer-test",
    "require-dev": {
        "psr/log": "*"
    },
    "require": {
        "oomphinc/composer-installers-extender": "*"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/ (require dependencies are installed before require-dev dependencies)

This seems to be a working fix - please try this approach and report back if it still does not work for you so I can continue troubleshooting. If it works consistently then I can update the readme to include this information.

Ultimately a true fix lies within composer itself, and I'm going to take a look to see what can be done there.

phenaproxima commented 7 years ago

Thanks, @balbuf, for your detailed response! However, I'm sorry to have to report that the fix you suggested doesn't seem to be working for me. Here is my composer.json, with the irrelevant parts removed:

{
    "name": "acquia/lightning",
    "description": "The best of Drupal, curated by Acquia",
    "type": "drupal-profile",
    "license": "GPL-2.0+",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "extra": {
    "installer-types": ["library"],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/libraries/{$name}": [
                "enyo/dropzone"
            ],
            "docroot/profiles/lightning/modules/contrib/{$name}": [
                "type:drupal-module"
            ]
        }
    },
    "require": {
        "cweagans/composer-patches": "^1.5.0",
        "oomphinc/composer-installers-extender": "^1.0",
        "drupal/core": "~8.3.1",
        "drupal/embed": "^1.0",
        "drupal/entity_embed": "1.0.0-beta2",
        "drupal/media_entity": "^1.0",
        "drupal/media_entity_instagram": "^1.0",
        "drupal/media_entity_twitter": "^1.3",
        "drupal/media_entity_image": "^1.0",
        "drupal/ctools": "^3.0",
        "drupal/panels": "^4.0",
        "drupal/page_manager": "^4.0",
        "drupal/panelizer": "^4.0",
        "drupal/scheduled_updates": "1.0.0-alpha6",
        "drupal/workbench_moderation": "1.2.0",
        "drupal/acquia_connector": "^1.1",
        "drupal/config_update": "^1.1",
        "drupal/features": "^3.0",
        "drupal/inline_entity_form": "^1.0",
        "drupal/metatag": "^1.0",
        "drupal/token": "^1.0",
        "drupal-composer/drupal-scaffold": "^2.0.0",
        "drupal/pathauto": "^1.0",
        "drupal/entity_browser": "1.0.0",
        "drupal/views_infinite_scroll": "^1.1",
        "drupal/media_entity_document": "^1.0",
        "drupal/video_embed_field": "^1.0",
        "drupal/contact_storage": "^1.0",
        "drupal/diff": "^1.0",
        "drupal/entity_block": "1.0.0-alpha2",
        "drupal/search_api": "^1.0",
        "drupal/layout_plugin": "^1.0@alpha",
        "enyo/dropzone": "^4.3"
    },
}

Have I missed something? (Hopefully :) But with this composer.json, enyo/dropzone is still installed in vendor/enyo/dropzone.

kasperg commented 7 years ago

I tested the composer.json provided by @phenaproxima and I see the same result: enyo/dropzone is still installed in vendor/enyo/dropzone.

I am mostly interested in this projects in correlation with https://asset-packagist.org. I tried with with the following adjustments (resulting json below):

  1. Add https://asset-packagist.org as repository
  2. Replace library with npm-asset in installer-types
  3. Replace enyo/dropzone with npm-asset for docroot/libraries/{$name}
  4. Change "enyo/dropzone": "^4.3" to "npm-asset/dropzone": "^4". For some reason I could not grok Composer does not recognize the 4.3.0 package and gets 4.2.0 instead.

Using this approach Dropzone ended up in docroot/libraries/dropzone/.

However if I subsequently delete the vendor and docroots folder but not composer.lock then Dropzone ends up in vendor/npm.asset/dropzone. In this case npm-asset/dropzone is also mentioned before oomphinc/composer-installers-extender in the Composer install log. Running composer install again will move Dropzone to docroot/libraries as per the original issue description. 

{
    "name": "acquia/lightning",
    "description": "The best of Drupal, curated by Acquia",
    "type": "drupal-profile",
    "license": "GPL-2.0+",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    ],
    "extra": {
        "installer-types": ["npm-asset"],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/libraries/{$name}": [
                "type:npm-asset"
            ],
            "docroot/profiles/lightning/modules/contrib/{$name}": [
                "type:drupal-module"
            ]
        }
    },
    "require": {
        "cweagans/composer-patches": "^1.5.0",
        "oomphinc/composer-installers-extender": "^1.0",
        "drupal/core": "~8.3.1",
        "drupal/embed": "^1.0",
        "drupal/entity_embed": "1.0.0-beta2",
        "drupal/media_entity": "^1.0",
        "drupal/media_entity_instagram": "^1.0",
        "drupal/media_entity_twitter": "^1.3",
        "drupal/media_entity_image": "^1.0",
        "drupal/ctools": "^3.0",
        "drupal/panels": "^4.0",
        "drupal/page_manager": "^4.0",
        "drupal/panelizer": "^4.0",
        "drupal/scheduled_updates": "1.0.0-alpha6",
        "drupal/workbench_moderation": "1.2.0",
        "drupal/acquia_connector": "^1.1",
        "drupal/config_update": "^1.1",
        "drupal/features": "^3.0",
        "drupal/inline_entity_form": "^1.0",
        "drupal/metatag": "^1.0",
        "drupal/token": "^1.0",
        "drupal-composer/drupal-scaffold": "^2.0.0",
        "drupal/pathauto": "^1.0",
        "drupal/entity_browser": "1.0.0",
        "drupal/views_infinite_scroll": "^1.1",
        "drupal/media_entity_document": "^1.0",
        "drupal/video_embed_field": "^1.0",
        "drupal/contact_storage": "^1.0",
        "drupal/diff": "^1.0",
        "drupal/entity_block": "1.0.0-alpha2",
        "drupal/search_api": "^1.0",
        "drupal/layout_plugin": "^1.0@alpha",
        "npm-asset/dropzone": "^4"
    }
}
kasperg commented 7 years ago

I started digging a bit more. As far as I can tell the situation is related to the specificity of version constraints.

Expanding on the examples by @balbuf:

Example 4

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "*",
        "psr/log": "1.0.2"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is installed to vendor/ instead of off-the-beaten-path/. Reinstalling from lock file will put files in the correct position.

Example 5

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "*",
        "psr/log": "^1.0"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/. Reinstalling from lock file will keep files in the correct position.

Example 6

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "1.1.2",
        "psr/log": "1.0.2"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/. Reinstalling from lock file will keep files in the correct position.

phenaproxima commented 7 years ago

I tried a few things and wanted to report on what has finally worked for me. As @kasperg said, tweaking the version constraints seems to have a positive effect. Here's my abbreviated composer.json, which installs things to the right place:

{
    "name": "acquia/lightning",
    "description": "The best of Drupal, curated by Acquia",
    "type": "drupal-profile",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    ],
    "extra": {
        "installer-types": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/libraries/{$name}": [
                "type:bower-asset",
                "type:npm-asset"
            ],
            "docroot/profiles/lightning/modules/contrib/{$name}": [
                "type:drupal-module"
            ]
        }
    },
    "require": {
        "cweagans/composer-patches": "^1.5.0",
        "oomphinc/composer-installers-extender": "^1.1",
        "drupal/core": "~8.3.1",
        "drupal/embed": "^1.0",
        "drupal/entity_embed": "1.0.0-beta2",
        "drupal/media_entity": "^1.0",
        "drupal/media_entity_instagram": "^1.0",
        "drupal/media_entity_twitter": "^1.3",
        "drupal/media_entity_image": "^1.0",
        "drupal/ctools": "^3.0",
        "drupal/panels": "^4.0",
        "drupal/page_manager": "^4.0",
        "drupal/panelizer": "^4.0",
        "drupal/scheduled_updates": "1.0.0-alpha6",
        "drupal/workbench_moderation": "1.2.0",
        "drupal/acquia_connector": "^1.1",
        "drupal/config_update": "^1.1",
        "drupal/features": "^3.0",
        "drupal/inline_entity_form": "^1.0",
        "drupal/metatag": "^1.0",
        "drupal/token": "^1.0",
        "drupal-composer/drupal-scaffold": "^2.0.0",
        "drupal/pathauto": "^1.0",
        "drupal/entity_browser": "1.0.0",
        "drupal/views_infinite_scroll": "^1.1",
        "drupal/media_entity_document": "^1.0",
        "drupal/video_embed_field": "^1.0",
        "drupal/contact_storage": "^1.0",
        "drupal/diff": "^1.0",
        "drupal/entity_block": "1.0.0-alpha2",
        "drupal/search_api": "^1.0",
        "drupal/layout_plugin": "^1.0@alpha",
        "bower-asset/dropzone": "^4",
        "drupal/dropzonejs": "1.0.0-alpha6"
    }
}

With this, bower-asset/dropzone is installed in docroot/libraries/dropzone, after deleting the lock file and running composer install. Making the dropzone constraint more specific (e.g., ^4.3) breaks it. Dunno what's up with that, but there you go.

phenaproxima commented 7 years ago

I've done a little more testing and discovered that Composer really does seem to be utterly non-deterministic about installation order for anything (including this package) that has more listed dependencies than php and composer-plugin-api. I can make this work on my local machine, but on Travis CI, the exact same composer.json things in the wrong location (bower-asset/dropzone comes first, then much later, oomphinc/composer-installers-extender -- meanwhile, composer/installers always goes straight to the front).

I'm not sure this can be solved at all until composer/composer#6371 is merged.

balbuf commented 7 years ago

I really appreciate all the additional investigative work! It does appear that, arbitrarily, certain factors such as version specificity and composer.json order have influence on whether this issue manifests itself, but ultimately the install order cannot be reliably controlled in that way. Thus, that is not a viable workaround unfortunately.

I'd like to see if we can get https://github.com/composer/composer/pull/6371 merged as the preferred solution, as that would reliably fix the issue for this plugin and any others out there that have their own dependencies.

Failing that, I would consider removing composer-installers as a dependency itself and replicate the underlying functionality that this plugin relies on, but I would consider that a last resort.

landsman commented 7 years ago

Thank you for your work! I have some idea: What about some response message back to the bash about moving these vendors, packages? Is it possible?

landsman commented 7 years ago

I don't know what I am doing bad, but right now it not working at all.

Jelle-S commented 7 years ago

FYI: installing this plugin globally solves the issue as well.

rodrigoaguilera commented 7 years ago

With following composer.json I can't make bootstrap-sass to install in a custom path. I tried changing the order of the requires, installing plugins globally, playing with the versions, running composer update and install several times.

Am I missing something

{
    "name": "oomphinc/composer-test",
    "repositories": [
    {
        "type": "composer",
        "url": "https://asset-packagist.org"
    }
    ],
    "require": {
        "oomphinc/composer-installers-extender": "1.1.2",
        "psr/log": "1.0.2",
        "bower-asset/bootstrap-sass": "3.3.7"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "otherpath": ["bower-asset/bootstrap-sass"],
            "thispath": ["psr/log"],
            "morepaths": ["type:npm-asset"]

        }
    }
}

It always get installed into vendor

rodrigoaguilera commented 7 years ago

Forget about that last comment, my "installer-types" was missing npm-asset and bower-asset as explained in the about page for that repo https://asset-packagist.org/site/about

raubin commented 7 years ago

Ok, thanks for the update @rodrigoaguilera !

balbuf commented 7 years ago

That is a great point @Jelle-S.

The issue here is that occasionally composer-installers-extender is not loaded and executed early enough; global plugins are always executed before the project composer.json is acted upon. Thus composer global require oomphinc/composer-installers-extender is a valid workaround; however, the implication is that this is going to be acting on every project whether or not it actually uses composer-installers-extender, and in some cases this could take precedence over other custom installers that a project actually intends to use. The other drawback is that this must be done before the regular composer install within the project, and it must be done manually by each user (only once though). Bottom line, this workaround could be helpful to some, but it does come with some drawbacks.

In the meantime, I am working with the composer folks to address the root issue there, and hopefully that can be worked out soon.

balbuf commented 7 years ago

Hi all! I just wanted to provide an update that the composer folks have accepted our pull request (https://github.com/composer/composer/pull/6371) which fixes the issue detailed in this thread. This fix is slated to be part of the 1.5 version release of composer, but it is unclear when that will drop.

In the meantime, you can use the update immediately by upgrading composer to the latest snapshot:

composer self-update --snapshot

This will upgrade composer to the latest snapshot of the master branch, which includes the fix for this issue. Be aware that this is not considered a stable release, so there could be bugs that haven't been worked out yet. However, it would be helpful to see if this fix works in all cases outlined above, so I encourage anyone willing to perform the upgrade and report whether this effectively resolves the issue.

If you'd like to just test the fix and go back to your previous installed version of composer, you can do so with:

composer self-update --rollback

or you can update to the latest stable release:

composer self-update --stable
maosmurf commented 7 years ago

Hi, please find minimal non-working demo at https://github.com/kurier/composer-bower-assets-order

First composer install puts bower-asset to vendor, only after second subsequent composer install the package is placed in correct folder.

balbuf commented 7 years ago

Hi @maosmurf - did you try upgrading composer to the latest snapshot release (composer self-update --snapshot) and try to install? There is a potential fix in composer's master branch but there has not been an official release that includes this yet.

maosmurf commented 7 years ago

Hi @balbuf - I can confirm that issue is solved in current composer snapshot (1.5-dev (189ba423aedc387a0487df40afc2428947406327) 2017-07-20 10:08:41)

Package of type bower-asset is placed correctly on first run of composer install, subsequent calls to composer install result correctly in "Nothing to install or update"

Thank you!

kasperg commented 7 years ago

Composer 1.5 is out now with the fix and I just confirmed that it still works for https://github.com/kurier/composer-bower-assets-order.

Thanks for your work @balbuf. I guess we can close this issue now. 🎉

cfoellmann commented 7 years ago

I am about to give up. I use this composer.json

{
    "name": "vendor/project",
    "description": "tbd",
    "type": "project",
    "config": {
        "preferred-install": "dist"
    },
    "license": "internal-only",
    "repositories": [
        {
            "type": "composer",
            "url": "https://www.phpmyadmin.net"
        }
    ],
    "require": {
        "oomphinc/composer-installers-extender": "^1.1",
        "phpmyadmin/phpmyadmin": "*"
    },
    "extra": {
        "installer-types": ["application"],
        "installer-paths": {
            "phpmyadmin/": ["phpmyadmin/phpmyadmin"]
        }
    }
}

and it doesn't work.

If I use 

{
    "name": "vendor/project",
    "description": "test",
    "type": "project",
    "config": {
        "preferred-install": "dist"
    },
    "license": "internal-only",
    "authors": [
        {
            "name": "Christian Foellmann",
            "email": "foellmann@foe-services.de"
        }
    ],
    "require": {
        "oomphinc/composer-installers-extender": "^1.1",
        "wp-cloud/phpmyadmin": "*"
    },
    "extra": {
        "installer-types": ["application"],
        "installer-paths": {
            "phpmyadmin/": ["wp-cloud/phpmyadmin"]
        }
    }
}

it works just fine. This uses a phpmyadmin package modified to be of the type application. But since the package from the phpmyadmin repo is now multi-language enabled I wanted to drop my own repo.

Any idea why I can't custom install the library type from the phpmyadmin repo?

daften commented 7 years ago

@cfoellmann I think that is a different issue than the one discussed here. I'd suggest opening up a separate issue for this :)

balbuf commented 7 years ago

@cfoellmann yes if you could open a new issue for this that would be great; I'm going to close this issue as there have been no new reports of the problem described herein since the release of Composer 1.5.

Nick-Hope commented 6 years ago

I am still suffering this problem with Composer 1.7.3 (in Ubuntu 18.04). The harvesthq/chosen library will not install in my web/libraries directory, no matter what I try; it always goes to the vendor directory. It won't even go there if I run composer update or composer install twice. As far as I can tell I have tried everything suggested in this thread. "Chosen" was specifically mentioned in this comment above by landsman, so maybe it is something specific to that package. Here's my composer.json in full. Note that I have already tried without harvesthq/chosen specified in the installer-paths section.

{
    "type": "project",
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        },
        {
            "type": "package",
            "package": {
                "name": "jackmoore/colorbox",
                "version": "1.6.4",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/jackmoore/colorbox/archive/1.6.4.zip",
                    "type": "zip"
                }
            }
        }
    ],
    "require": {
        "composer/installers": "^1.5",
        "oomphinc/composer-installers-extender": "^1.1.2",
        "cweagans/composer-patches": "^1.6.5",
        "drupal-composer/drupal-scaffold": "^2.5",
        "drupal/admin_toolbar": "^1.24",
        "drupal/allowed_formats": "^1.1",
        "drupal/better_exposed_filters": "^3.0@alpha",
        "drupal/chosen": "^2.6",
        "drupal/colorbox": "^1.4",
        "drupal/console": "^1.0.2",
        "drupal/core": "^8.6.3",
        "drupal/ctools": "^3.0",
        "drupal/facets": "1.1",
        "drupal/field_permissions": "^1.0@rc",
        "drupal/geolocation": "2.x-dev",
        "drupal/hierarchical_term_formatter": "^1.0@beta",
        "drupal/image_style_quality": "^1.3",
        "drupal/media_taxonomy_filter": "2.x-dev",
        "drupal/pathauto": "^1.3",
        "drupal/quicktabs": "^3.0@alpha",
        "drupal/search_api": "^1.10",
        "drupal/search_api_autocomplete": "^1.1",
        "drupal/shs": "^1.0@alpha",
        "drupal/superfish": "^1.2",
        "drupal/taxonomy_manager": "^1.0@alpha",
        "drupal/taxonomy_menu": "^3.3",
        "drupal/token": "^1.5",
        "drupal/tvi": "^1.0@beta",
        "drupal/video_embed_field": "^2.0@alpha",
        "drupal/views_arg_order_sort": "1.x-dev",
        "drupal/views_contextual_filters_or": "^1.0",
        "drupal/views_infinite_scroll": "^1.5",
        "bower-asset/jquery-ui-slider-pips": "^1.11.4",
        "jackmoore/colorbox": "^1.6.4",
        "vlucas/phpdotenv": "^2.5.1",
        "webflo/drupal-finder": "^1.1",
        "webmozart/path-util": "^2.3",
        "wikimedia/composer-merge-plugin": "^1.4.1",
        "harvesthq/chosen": "^1.8"
    },
    "require-dev": {
        "drupal/devel": "^1.2",
        "webflo/drupal-core-require-dev": "^8.6.2"
    },
    "conflict": {
        "drupal/drupal": "*"
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "config": {
        "preferred-install": "dist",
        "autoloader-suffix": "Drupal8"
    },
    "autoload": {
        "psr-4": {
            "Drupal\\Core\\Composer\\": "core/lib/Drupal/Core/Composer"
        }
    },
    "scripts": {
        "pre-autoload-dump": "Drupal\\Core\\Composer\\Composer::preAutoloadDump",
        "post-autoload-dump": "Drupal\\Core\\Composer\\Composer::ensureHtaccess",
        "post-package-install": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
        "post-package-update": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
        "drupal-phpunit-upgrade-check": "Drupal\\Core\\Composer\\Composer::upgradePHPUnit",
        "drupal-phpunit-upgrade": "@composer update phpunit/phpunit phpspec/prophecy symfony/yaml --with-dependencies --no-progress",
        "phpcs": "phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --",
        "phpcbf": "phpcbf --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --"
    },
    "extra": {
        "_readme": [
            "By default Drupal loads the autoloader from ./vendor/autoload.php.",
            "To change the autoloader you can edit ./autoload.php.",
            "This file specifies the packages.drupal.org repository.",
            "You can read more about this composer repository at:",
            "https://www.drupal.org/node/2718229"
        ],
        "enable-patching": true,
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "installer-types": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": [
                "type:drupal-library",
                "type:bower-asset",
                "type:npm-asset",
                "harvesthq/chosen"
            ],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/contrib/{$name}": ["type:drupal-drush"],
            "web/modules/custom/{$name}": ["type:drupal-custom-module"],
            "web/themes/custom/{$name}": ["type:drupal-custom-theme"]
        },
        "drupal-scaffold": {
            "initial": {
                ".editorconfig": "../.editorconfig",
                ".gitattributes": "../.gitattributes"
            }
        },
        "merge-plugin": {
            "include": [
                "core/composer.json",
                "web/modules/custom/*/composer.json"
            ],
            "recurse": true,
            "replace": false,
            "merge-extra": false,
            "ignore-duplicates": true
        },
        "patches": {
            "drupal/core": {
                "Render action button above parent entity": "https://www.drupal.org/files/issues/preview-comment-aoutput-below-2927874-2.diff",
                "Hide undefined index errors on all pages": "https://www.drupal.org/files/issues/filterpluginbase-filter-notices.patch"
            },
            "drupal/geolocation": {
                "Respect initial zoom value": "https://www.drupal.org/files/issues/2018-11-02/geolocation-respect-initial-zoom-level-2945234-60.patch"
            },
            "drupal/facets": {
                "Display titles on slider facets": "https://www.drupal.org/files/issues/2018-10-18/3002580_6.patch"
            },
            "drupal/views_arg_order_sort": {
                "Fix SQL injection attack vulnerability": "https://www.drupal.org/files/issues/2018-10-19/views-arg-order-sort-sql-injection-fix-2982591-5.patch"
            }
        }
    }
}
balbuf commented 6 years ago

Hi @Nick-Hope, I opened a new issue and will respond there: https://github.com/oomphinc/composer-installers-extender/issues/16.

I am going to lock this conversation to avoid bothering folks on this thread. For anyone that comes across this issue and experiences something similar, please open a new issue! (Feel free to reference this issue if appropriate.) Thank you!