Skip to content
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

Conflict with vimeo/psalm prohibits the installation of plugins #14

Open
boesing opened this issue Aug 16, 2022 · 6 comments
Open

Conflict with vimeo/psalm prohibits the installation of plugins #14

boesing opened this issue Aug 16, 2022 · 6 comments

Comments

@boesing
Copy link

boesing commented Aug 16, 2022

Hey there,

most plugins usually require vimeo/psalm in a specific version.
I wonder if it is possible to actually change conflict to replace while using self.version.

For every psalm release, there is also a version in here.
This way, this component can actually provide vimeo/psalm in a specific version and also allows plugins to be installed while keeping composer dependency tree up and running.

Thoughts?
Or do you have reasons for explicitly conflicting with vimeo/psalm?

@boesing
Copy link
Author

boesing commented Aug 18, 2022

@orklah do you know if this repository is maintained by any1?

https://muglug.medium.com/my-incredible-journey-with-php-df45d72ba2a5

@orklah
Copy link

orklah commented Aug 18, 2022

Hey! Possibly me, but I have no idea why the conflict was declared and what are the consequences of changing that

@boesing
Copy link
Author

boesing commented Aug 24, 2022

I'd say that the conflict was added to avoid confusions when installing vendor/bin/psalm (from vimeo/psalm) & vendor/bin/psalm.phar (from psalm/phar).

So I think a replace would suffice. Having this in the composer.json should work:

{
  "name": "psalm/phar",
  "description": "Composer-based Psalm Phar",
  "license": [
    "MIT"
  ],
  "require": {
    "php": "^7.1 || ^8.0"
  },
  "replace": {
    "vimeo/psalm": "self.version"
  },
  "bin": [
    "psalm.phar"
  ],
  "config": {
    "platform-check": false
  }
}

https://getcomposer.org/doc/04-schema.md#replace

Caution is advised when using replace for the sub-package purpose explained above. You should then typically only replace using self.version as a version constraint, to make sure the main package only replaces the sub-packages of that exact version, and not any other version, which would be incorrect.

This would actually only replace the same version rather than "any".

@boesing
Copy link
Author

boesing commented Aug 24, 2022

The question is, if that would suffice. Depending on how the phar file is created, the namespace might not be correct anymore. If so, plugins won't work as they implement interfaces of psalms namespace.
Maybe thats another (or the real) reason of why conflict was used.

@rela589n
Copy link

Hi @boesing , did you figure out if there are any workarounds that would allow using plugins with phar installation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants