-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package type "library" is not supported #26
Package type "library" is not supported #26
Comments
I'm also seeing this - on a previous project with composers-installers-extender 1.1, this error didn't happen I downgraded to 1.1.2, and it's no longer occurring |
I tracked down the change that caused this but the composer behavior is super weird and undocumented. In 2.0 we have this code: composer-installers-extender/src/Installers/CustomInstaller.php Lines 16 to 18 in 8d3fe38
Where in 1.0 the code looked like this: composer-installers-extender/src/InstallerHelper.php Lines 7 to 15 in ca1c4b1
Now, that ends up interacting with this code in different ways as documented in the comment even though composers behavior seems completely broken. The key is these two lines $packageType = substr($type, strlen($frameworkType) + 1);
if (!isset($locations[$packageType])) {
throw new \InvalidArgumentException(sprintf('Package type "%s" is not supported', $type));
}
return $this->templatePath($locations[$packageType], $availableVars); Basically what we see is that Next is less important but templatePath returns false because Now, it doesn't actually make any sense to check the 0th index, relying on undocumented type conversion, relying on passing a boolean into strpos, and the undocumented return types(getInstallPath only claims to return strings which clearly isn't the case). But all this seems to be expected in composer just not documented so I think we just return the old code? Sorry for the ranting but a single comment along this chain in composer would have saved me several hours of headaches trying to sort this out so the composer team can deal if they end up reading this I think. PR incoming. |
Nice detective work @neclimdul It seems |
Thanks :) You're probably right. That definitely makes some sense and then all this is just hacking a value through so handle non-namespaced types can be handled here.
Maybe that's a good suggestion but I think the problem with changing it is its being used in places like chosen and at least with chosen I'm not sure if we're going to be able to change it. |
I agree we probably can't change that. So perhaps we can extend public function getInstallPath(PackageInterface $package, $frameworkType = '')
{
if ($frameworkType == $this->package->getType()) {
// Do something.
}
else {
return parent::getInstallPath($package, $frameworkType);
}
} |
That sort of makes sense. My intent was the shortest path to fixing the 2.x branch and getting some composer2 testing so reverting to the previous behavior was my first reaction. I'll see if I can find some time though to continue diving into composer installers and see if the [false] return is interacting with the other calls in anyway or if short circuiting the call in getInstallPath makes more sense. |
As a workaround (at least for the chosen library) you can define a custom repository for the chosen library (which is no longer updated anyway) in your project composer.json and set it's package:type to drupal-library. This seems to override the package:type in the chosen library source composer.json. "repositories": {
"chosen": {
"type": "package",
"package": {
"name": "harvesthq/chosen",
"version": "1.8.7",
"type": "drupal-library",
"dist": {
"url": "https://github.com/harvesthq/chosen/releases/download/v1.8.7/chosen_v1.8.7.zip",
"type": "zip"
}
}
},
}, Then you can require as usual with: "require": {
"harvesthq/chosen": "^1.8",
}, And define the installer-paths like: "installer-paths": {
"docroot/libraries/{$name}": [
"type:drupal-library"
],
}, Attempting to use installer-paths options for specific package name ( |
To prevent ``` [InvalidArgumentException] Package type "library" is not supported ``` after running `composer update --no-dev --ignore-platform-reqs` see also: oomphinc/composer-installers-extender#26
I am not sure but I believe the solution is to use https://github.com/mnsami/composer-custom-directory-installer for type library. |
@tobiasbaehr that definitely have helped, so thanks! At least in my case, for chosen in drupal. Basically after requiring
chosen is placed in the proper location. |
I'm having a similar issue with |
The drupal/fontawesome package does not require the Font Awesome library on its own, so we have to hack it around with custom install path to enforce the package into the Drupal libraries folder. oomphinc/composer-installers-extender#26 https://www.drupal.org/project/fontawesome/issues/2839928
This appears blocked on the discussion raised at #26 (comment) but is addressed in #27 which is rather narrow. I think merging that PR (once all outstanding items are resolved re: approach) is the most straightforward approach here. For what it's worth, adding that PR as a patch to the installer and then re-running affected patches (after adding back |
sorry for the delay. I had to detour through some other problems before getting back to this but doing that audit now. |
Cool! @mstenta So existing tests ended up being really useful here. I started thinking it probably could be pretty simple but tests like Seems there are no good options here really. Sorry. Let me know what you think. PS - I found that the plugin tests where failing unrelated to anything I was doing here. I'm not immediately sure how they where previously passing or maybe they weren't but #33 should fix that. |
This PR works for me. |
@neclimdul I agree that this approach is the simplest way forward. |
For some reason, the PR fixes the problem for me when running composer on PHP 7.4.5, but not when running the same composer in PHP 8.0.3. Literally the only difference is the php interpreter used, and the effect on PHP 8 is still "Package type library is not supported.". I'm currently trying to investigate. Update: From the earlier investigation by @neclimdul, I think I see what's happening:
(I'm not sure if the second affected array lookups, but whether or not The combination of these two will mean that $packageType = substr($type, strlen($frameworkType) + 1);
if (!isset($locations[$packageType])) {
throw new \InvalidArgumentException(sprintf('Package type "%s" is not supported', $type));
} with I can't begin to understand what composer's intended logic is, but I suspect that we can get the effect we wanted by changing function getLocations() {
return array( false );
} to function getLocations() {
return array(0 => false , "" => false);
} I hope. Update: After installing the patch with the above modification, I can add "library" to the installer-types array without causing an error in PHP 8. |
Thanks for testing! That's a great find. Also, omg why would they do that.... That's not even very clear from the docs either. It looks very much from the main return docs like it will always return false from my reading. :( Agreed on understanding composers logic. Its a sea of code without comments but your reading matches my digging and the way I had hacked this in. |
btw, free free to provide technical feedback on !27. I'm not sure everyone following this cares about every bug. Also, this can be really annoying to test since you can't patch it with composer-patches or the like before composer starts running it. This means its impossible to really test a clean install from scratch. For my testing I created https://packagist.org/packages/neclimdul/composer-installers-extender and feel free to use it for your testing as well. But, as noted in the README, I do not plan on maintaining this so don't rely on it. Its only a testing package for this issue that I'll be deleting as soon as a solution for this is merged. |
This PR definitely worked for me. |
This works for me:
It seems to be as simple as |
@syzygy333 indeed! But you can't control what the packages you want to require have as their types - at least not without overriding the package data as per #26 (comment) , which then makes updating/maintaining those packages harder. So in that example of harvesthq/chosen - you can't require that package without doing something awkward, unless this could be fixed in oomphinc/composer-installers-extender . |
Is that not what this is doing?
|
@syzygy333 no - that's configuring where to put each package that you require, of those types. So if you require a package that declares itself to have the |
I've found a workaround using Drupal Scaffold operations. I got utterly fed-up of the Chosen library sometimes installing in the right place, and sometimes not, despite having followed the guides above and the work of several other people with the same problems. As an example, out of the nine D9 sites I maintain - which all use the same composer.json file - Composer on five of the nine sites abjectly refused to put the Chosen library in the correct location, while on the other two sites it worked just fine. A diff of the composer.jsons between working and non-working sites showed no obvious differences. So, I'm using Drupal Scaffold as follows: 1: In the root of the repo at the same level as composer.json, I created a build-assets/ directory and added chosen.jquery.js and chosen.jquery.min.js, giving a directory structure of:
2: In composer.json, in the extra > drupal-scaffold > file-mapping section, add maps which will copy the two Chosen JS files into web/libraries/chosen/ after build:
(Obviously the above sections in your composer.json will have other entries in them.) To test, I ran Hopefully this helps someone else! :) Alex |
Good idea to share a workaround ... I've worked around the problem in a slightly different way, which avoids the need for including the assets in my repo. I define the chosen library as a drupal-library with a {
...
"repositories": [
{
"type": "package",
"package": {
"name": "harvesthq/chosen",
"version": "v1.8.7",
"type": "drupal-library",
"extra": {
"installer-name": "chosen"
},
"dist": {
"url": "https://github.com/harvesthq/chosen/releases/download/v1.8.7/chosen_v1.8.7.zip",
"type": "zip"
},
"require": {
"composer/installers": "~1.0"
}
},
"only": ["harvesthq/chosen"]
}
],
"require": {
"composer/installers": "^1.9",
"harvesthq/chosen": "^1.8.7"
},
"extra": {
"installer-paths": {
"webroot/libraries/{$name}": [
"type:drupal-library",
"harvesthq/chosen"
]
}
},
"config": {
"allow-plugins": {
"composer/installers": true
}
}
} This also ends up with |
Yep, except that’s the approach I’m using which all of a sudden only works
on two out of nine sites… :-/
On Tue, 5 Apr 2022 at 17:10, James Williams ***@***.***> wrote:
Good idea to share a workaround ... I've worked around the problem in a
slightly different way, which avoids the need for including the assets in
my repo. I define the chosen library as a drupal-library with a
repositories entry, so that composer/installers puts it in the right
place (without even needing to use oomphinc/composer-installers-extender
!):
{
...
"repositories": [
{
"type": "package",
"package": {
"name": "harvesthq/chosen",
"version": "v1.8.7",
"type": "drupal-library",
"extra": {
"installer-name": "chosen"
},
"dist": {
"url": "https://github.com/harvesthq/chosen/releases/download/v1.8.7/chosen_v1.8.7.zip",
"type": "zip"
},
"require": {
"composer/installers": "~1.0"
}
},
"only": ["harvesthq/chosen"]
}
],
"require": {
"composer/installers": "^1.9",
"harvesthq/chosen": "^1.8.7"
},
"extra": {
"installer-paths": {
"webroot/libraries/{$name}": [
"type:drupal-library",
"harvesthq/chosen"
]
}
},
"config": {
"allow-plugins": {
"composer/installers": true
}
}
}
This also ends up with webroot/libraries/chosen/chosen.jquery.min.js 👍
It just means that if I ever want to upgrade the chosen library, I'll need
to update the repositories entry. But @alexharriesredactive
<https://github.com/alexharriesredactive>'s suggested solution would also
need a manual step (of replacing the downloaded assets).
—
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANCE7D3TXRQH4KY5VJWOVEDVDRQWBANCNFSM4RETOF3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
|
i am not using this in drupal but in wordpress and currently it is a blocker if using php > 8.1 and composer v2. No idea of a workaround i can apply. Does anyone have any idea? |
@bizmate We've been using this suggestion but we forked it to mark it as a replacement of this package: |
@nicolas-girod thank you for the feedback. I ended up using composer 1 again and specifying
as it was suggested previously. I think this is ok as a workaround for now :) |
When I run
composer require <package>
with v2.0.0, it errors out:Composer
1.10.13
oomphinc/composer-installers-extender:2.0.0
composer.json
:The text was updated successfully, but these errors were encountered: