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

Controlling conflict resolution in merge_with #1191

Open
slavaGanzin opened this issue Aug 20, 2024 · 1 comment
Open

Controlling conflict resolution in merge_with #1191

slavaGanzin opened this issue Aug 20, 2024 · 1 comment

Comments

@slavaGanzin
Copy link

I was tryin to merge two configs, one docker-compose and docker-compose.swarm override. Swarm do not understand object for depends_on, answer should be only a list.

#docker-compose
services:
  service1:
    # some other args
    depends_on: 
      service2:
        condition: healthy

#docer-compose.swarm just to override depends_on
services:
  service1:
     depends_on:
        - service2
    compose = OmegaConf.load(compose_file)
    override = OmegaConf.load(replace('.yaml', '.swarm.yaml', compose_file))
    swarm = compose.merge_with(override)
    
    #which will throw this:
    omegaconf.errors.ConfigTypeError: Cannot merge DictConfig with ListConfig
    full_key:
    object_type=dict

First of all it will be really useful to show what can't be merged.
Second, Dict and Map couldn't be merged, but that's not what I need, and there is no way to change this behavior: I couldn't catch an error on specific key and fix it. OmegeConf do not return any information for me to fix it.
Third, it would be really helpful to have an ability to pass resolution function, like ramda do https://ramdajs.com/docs/#mergeWith

swarm = compose.merge_with(override, lambda a,b: b)

So when conflict arises, I just use right value.

@slavaGanzin slavaGanzin changed the title Function argument for controlling conflict resolution in merge_merge Controlling conflict resolution in merge_with Aug 20, 2024
@slavaGanzin
Copy link
Author

And there is no easy way to monkey patch this behavior either

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

1 participant