[Auto3DSeg] Add mlflow support in autorunner.

[dongyang0122]

Add MLflow support in AutoRunner Class.

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Integration tests passed locally by running ./runtests.sh -f -u --net --coverage.
• Quick tests passed locally by running ./runtests.sh --quick --unittests --disttests.
• In-line docstrings updated.
• Documentation updated, tested make html command in the docs/ folder.

[myron]

I think this should be a part of kwargs of Autorunner, instead of adding more names parameters for very specific use case.

Then you check for it as
If kwargs.get('mlflow_url', None) is not None:

[drbeh]

I think this should be a part of kwargs of Autorunner, instead of adding more names parameters for very specific use case.

Then you check for it as If kwargs.get('mlflow_url', None) is not None:

@myron @dongyang0122 As the zen of python says "explicit is better than implicit". In my opinion, having more names means better documentation. Deferring to kwargs usually makes sense when dealing with a third party parameters that might change over time without our notice, but mlflow_tracking_uri is our parameter and we decide how to use it (although we are passing it to mlflow).

[dongyang0122]

I think this should be a part of kwargs of Autorunner, instead of adding more names parameters for very specific use case.
Then you check for it as If kwargs.get('mlflow_url', None) is not None:

@myron @dongyang0122 As the zen of python says "explicit is better than implicit". In my opinion, having more names means better documentation. Deferring to kwargs usually makes sense when dealing with a third party parameters that might change over time without our notice, but mlflow_tracking_uri is our parameter and we decide how to use it (although we are passing it to mlflow).

I acknowledge the perspectives presented from both sides. Incorporating an input variable mlflow_tracking_uri would enhance parameter visibility and documentation, whereas including it under ‘kwargs’ could conserve script space. Personally, I favor the first approach, though both methods are viable. Input from individuals @Nic-Ma and @daguangxu on this matter would be beneficial to finalize the decision.

[Nic-Ma]

Hi @drbeh , @dongyang0122 ,

Do we have any usecase to allow users to set experiment_name? If no, I would vote for current implementation with mlflow_tracking_uri arg directly.

Thanks.

[Nic-Ma]

/black

[wyli]

/build

[wyli]

/build

[wyli]

/build