New "conflicts" property for .info.yml extension files

Created on 19 March 2010, about 15 years ago
Updated 12 February 2025, about 2 months ago

What if, in the same way a module can specify that it depends on another module (and perhaps soon, on what version), it could specify that it incompatible with another module? Some modules, of course, just don't work together, and I wonder if it wouldn't save site builders time pulling their hair out diagnosing known issues and save module maintainers time responding to issues by people who overlooked compatibility notices on the module pages. It's just a thought. :)

✨ Feature request
Status

Needs work

Version

11.0 πŸ”₯

Component

extension system

Created by

πŸ‡ΊπŸ‡ΈUnited States traviscarden

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¬πŸ‡·Greece vensires

    The main question here is what's the action expected when a conflict is found. Depending on what we want the action to be, just by using hook_requirements() we might be ok.

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    You absolutely can do this with hook_requirements, the plan is to replace the conflicts piece with info yaml or composer.json

  • πŸ‡¬πŸ‡·Greece vensires

    So far, we have hook_requirements() - which can be bypassed if you use -y in drush, and composer's which may or may not be used for custom modules. My question remains: let's say we have a conflict in *.info.yml; is it there for informational reasons or should it 100% prohibit the coexistence of the module without any bypass?

  • πŸ‡¦πŸ‡ͺUnited Arab Emirates beautifulmind Dubai

    I think it should stop the operation entirely.

    Also, adding 'for information purpose' now seems pointless since it'll probably be just taken it out later, saying it's not needed.

    Cheers,
    Beautifulmind

Production build 0.71.5 2024