Ambiguous logic contract instance when deploying upgradeable contract

[cygnusv]

Traceback (most recent call last):
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/bin/ape", line 8, in <module>
    sys.exit(cli())
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/ape/_cli.py", line 79, in invoke
    return super().invoke(ctx)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/ape_run/_cli.py", line 74, in invoke
    return super().invoke(ctx)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/ape/cli/commands.py", line 96, in invoke
    return self._invoke(ctx, provider=provider)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/ape/cli/commands.py", line 133, in _invoke
    return ctx.invoke(self.callback or (lambda: None), **ctx.params)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
  File "/Users/david/.local/share/virtualenvs/nucypher-contracts-QkvTNaSR/lib/python3.10/site-packages/ape_run/_cli.py", line 151, in call
    main_ns["main"]()  # Execute the script
  File "/Users/david/dev/nu/nucypher-contracts/scripts/lynx/deploy_bqeth.py", line 21, in main
    bqeth_subscription = deployer.deploy(project.BqETHSubscription)
  File "/Users/david/dev/nu/nucypher-contracts/deployment/params.py", line 573, in deploy
    contract_type_container, resolved_proxy_params = self.proxy_parameters.resolve(
  File "/Users/david/dev/nu/nucypher-contracts/deployment/params.py", line 441, in resolve
    resolved_params = _resolve_params(parameters=proxy_info.constructor_params)
  File "/Users/david/dev/nu/nucypher-contracts/deployment/params.py", line 193, in _resolve_params
    resolved_parameters[name] = _resolve_param(value)
  File "/Users/david/dev/nu/nucypher-contracts/deployment/params.py", line 185, in _resolve_param
    return value.resolve()
  File "/Users/david/dev/nu/nucypher-contracts/deployment/params.py", line 148, in resolve
    contract_instance = _get_contract_instance(contract_container)
  File "/Users/david/dev/nu/nucypher-contracts/deployment/params.py", line 170, in _get_contract_instance
    raise ValueError(
ValueError: Variable BqETHSubscription is ambiguous - expected exactly one contract instance, got 2 Checkout ~/.ape/<NETWORK>/deployments_map.json

Workaround is to rm -rf ~/.ape/<NETWORK>/, but there has to be a better way!

[KPrasch]

This is a known design flaw when handling upgradeable contracts. Ape keeps a cache of deployments that is used as a way to lookup deployment details of a previously deployed proxy contract. However, if there is more than one entry in this ape cache we do not have any means of disambiguating which deployment instance the user is trying to interact with. Instead of accepting the additional complexity of disambiguation we decided to raise this error instead.

Workaround is to rm -rf ~/.ape//, but there has to be a better way!

This is the most simple solution and It can even be adopted as a long-term solution by automating the deletion of specific cache entries. It's acceptable to just delete it since we're using our own deployment metadata tracking system instead of ape's. The effort vs. benefit of trying to wrap the cache with additional context is not good imo.

Related to #143