MLFlowLogger Issues with LightningCLI

[drc-sbelcher]

I'm having trouble working around an issue that arises due to the save_dir property of the MLFlowLogger returning None when tracking_uri is set. The SaveConfigCallback setup method makes the assertion that log_dir is not None, but log_dir is assigned as trainer.log_dir, which is set to the logger's save_dir attribute, which for some reason returns None in the MLFlowLogger when you are using a remote tracking server. I was hoping I could simply intervene and manually override the trainer.log_dir property, but it's read-only so that doesn't work. This seems fundamentally broken and ought to be fixed in general, but I was hoping someone else had run into this issue and has a workaround that I can use for now.

Edit: I temporarily fixed this by extending the SaveConfigCallback class to override the setup method. My updated version is exactly the same, but it replaces

log_dir = trainer.log_dir

with

log_dir = trainer.log_dir or trainer.default_root_dir

I don't know if this has potential downstream consequences, but for my use case it got things running properly.

[mazzma12]

It looks to me that it's still the case. I can't have a MLFlowLogger alone in remote tracking mode, I need to setup a TensorboardLogger to to setup the log_dir properly

[mauvilsa]

If you are using mlflow, my recommendation would be to implement a subclass of SaveConfigCallback that saves the config in mlflow as an artifact, and doesn't save to the log dir (i.e. save_to_log_dir=False see cli.py#L242-L243). I mean, what is the point of having the config saved locally if the idea is to store things in mlflow?

If for some reason someone truly wants to use mlflow and save the config locally, then I don't see why not creating a pull request that does the log_dir = trainer.log_dir or trainer.default_root_dir change proposed above. It would be a simple and good first time contribution.