ValueError: configuration key 'navigate_workflow_dir' already defined

[ravitby]

Running the following command in the terminal:

mix-models il-transport run "S1 reported" --go

Produce the following error:

Traceback (most recent call last):
  File "/opt/miniconda3/envs/ME_X86_P3.10/bin/mix-models", line 5, in <module>
    from message_ix_models.cli import main
  File "/Users/ravitb/Workspace/TAU/ilTransport/message-ix-models/message_ix_models/cli.py", line 202, in <module>
    __import__(name)
  File "/Users/ravitb/Workspace/TAU/ilTransport/message_data/message_data/model/buildings/cli.py", line 6, in <module>
    from message_data.projects.navigate.cli import _SCENARIO
  File "/Users/ravitb/Workspace/TAU/ilTransport/message_data/message_data/projects/navigate/__init__.py", line 21, in <module>
    ixmp.config.register(
  File "/Users/ravitb/Workspace/TAU/ilTransport/ixmp/ixmp/_config.py", line 286, in register
    self._ValuesClass, self.values = self.values.add_field(
  File "/Users/ravitb/Workspace/TAU/ilTransport/ixmp/ixmp/_config.py", line 93, in add_field
    raise ValueError(f"configuration key {repr(name)} already defined")
ValueError: configuration key 'navigate_workflow_dir' already defined

[glatterf42]

Thank you for reporting your issue!
Please refrain from assigning it so specific people, though, we will do that ourselves as it makes sense.

In this case, the error message states configuration key 'navigate_workflow_dir' already defined. So the ixmp Config is trying to read in all relevant values and encounters this value twice, so it doesn't know what to do and raises an error.
It's very hard to tell from the outside why this is happening. Please first run something like ixmp config show on the command line. This will tell you where your config file lives and what its contents are. They probably contain one of the occurrences of navigate_workflow_dir. My best guess for the other occurrence is within the message_data/projects/navigate/__init__.py file, where it used to be defined from line 21 to 25.
Please note I'm saying 'used to' because the current dev version of the file does not contain this config setting anymore. @khaeru recently migrated the transport code to message-ix-models ( 🎉 ) and cleaned up in message_data in the process. So to keep up with this development, I would recommend pulling the latest changes from both repositories to your hopefully editable install whenever there is some time.
For the current issue, I think you can resolve it by removing all but one of the times that navigate_workflow_dir is defined. Instead of just trusting my analysis, I also advice you to search your code base for this name and see where it is defined. Then, you can determine yourself which of these is the appropriate one to keep. From our point of view, it's in the ixmp Config file because this can serve as a common location between several projects so that we can avoid duplicating code in every message_data/projects/... folder.

[khaeru]

This is indeed due to #207. What is happening:

1. With Migrate message_data.model.transport #207, there is code here that defines the configuration key "navigate_workflow_dir":

   message-ix-models/message_ix_models/project/navigate/__init__.py

   Lines 22 to 26 in cf687da

   	ixmp.config.register(
   	"navigate workflow dir",
   	Path,
   	cast(Path, MESSAGE_MODELS_PATH).parent.joinpath("navigate-workflow"),
   	)

2. On message_data dev branch, there was also the same code in its pre-migration location: https://github.com/iiasa/message_data/blame/1275d9347bd8b7890d5eb21760bc55743790b8e1/message_data/projects/navigate/__init__.py#L22-L26
3. ixmp.config.register() is intended to only be called once per key (to avoid confusion from the same configuration key being defined in multiple places, with conflicting types and defaults).
4. Importing message_data.projects.navigate (2) after message_ix_models (1) triggers (3).

As @glatterf42 notes, there was some clean-up (iiasa/message_data#571) that removed this duplication.

@ravitby, I have on my TODO list to help with iiasa/message_data#559; this will include rebasing it on the latest message_data dev (i.e. after the merge of iiasa/message_data#571). You could also try that yourself, if you like, but no pressure. That should cause the error to disappear.