Vim-mlflow: A Vim plugin to view in Vim the tables and info one sees in MLFlow... without leaving Vim.
I love MLflow a lot, and I use it all the time for both work and personal projects. (If you do too you may find my quick-mlflow-setup page useful; it's what populated the example MLflow contents in the images below.) There are projects in which I go all-out and auto-log extensive graphical artifacts to better enable modeling improvements - like with example images for the different error cases, and ROC curves, and so on. And it's really convenient to use its website as a one-stop UI to where those artifacts are logged and reviewed by others. But there are also a lot of projects where I really don't log much more than the modeling parameters and performance metrics, just numbers, and I'm still leaving my terminal-based workflow in Vim and looking up and comparing those numbers on the (in this case needlessly point-and-click) MLflow website.
Call me one of those crotchety Linux terminal lovers who's all about their terminal apps. But in this frequent special case I'd much prefer to simply access the MLflow database contents without leaving my terminal - better yet without leaving Vim. MLflow does in fact have a CLI (which is pretty central to its usage as well), but that's not the browsing capability that I'm talking about here - I want to quickly and easily browse the results just like in the MLflow website.
So I took a dive into creating my first Vim plugin to provide this, in vim-mlflow. As my first Vim plugin, it is a beginning (but fully functional) work in progress, so there are some important caveats to note in advance -- this thing will continue to improve as it goes forward. It does require the MLFlow python package to be installed in the environment that Vim is run in, and a version of Vim that supports python3. Also, in the preliminary way I set up the plug-in, vim-mlflow requeries the MLFlow server at each navigation step. As long as the user is running Vim on the same machine as the MLFlow server, or the network connection between the two is fast (say on same LAN), there's little problem here, even with the fairly-extensive MLFlow database I run in my workplace. However, when the systems running Vim and the MLFlow server are separated by a slower or less consistent network connection (e.g. running Vim on a machine at home connecting to MLFlow server at work), then things can be excruciatingly slow. It's all down to the speed of your database server and of your network access from your Vim process to that database server. There's no question this should be revamped and taken care of, and it will, but meanwhile the thing is fully functional in this fairly common use-case, and highly configurable in terms of layout, syntax coloring, and so on.
See its Github repo for more detail, but in general you just enter vim-mlflow mode in your Vim session, browse around among different experiments and runs in the sidebar, mark runs of interest, and then view those marked runs together (including from different experiments) in the Marked Runs buffer in which one can further filter columns and contents to compare the runs.
I love MLflow a lot, and I use it all the time for both work and personal projects. (If you do too you may find my quick-mlflow-setup page useful; it's what populated the example MLflow contents in the images below.) There are projects in which I go all-out and auto-log extensive graphical artifacts to better enable modeling improvements - like with example images for the different error cases, and ROC curves, and so on. And it's really convenient to use its website as a one-stop UI to where those artifacts are logged and reviewed by others. But there are also a lot of projects where I really don't log much more than the modeling parameters and performance metrics, just numbers, and I'm still leaving my terminal-based workflow in Vim and looking up and comparing those numbers on the (in this case needlessly point-and-click) MLflow website.
Call me one of those crotchety Linux terminal lovers who's all about their terminal apps. But in this frequent special case I'd much prefer to simply access the MLflow database contents without leaving my terminal - better yet without leaving Vim. MLflow does in fact have a CLI (which is pretty central to its usage as well), but that's not the browsing capability that I'm talking about here - I want to quickly and easily browse the results just like in the MLflow website.
So I took a dive into creating my first Vim plugin to provide this, in vim-mlflow. As my first Vim plugin, it is a beginning (but fully functional) work in progress, so there are some important caveats to note in advance -- this thing will continue to improve as it goes forward. It does require the MLFlow python package to be installed in the environment that Vim is run in, and a version of Vim that supports python3. Also, in the preliminary way I set up the plug-in, vim-mlflow requeries the MLFlow server at each navigation step. As long as the user is running Vim on the same machine as the MLFlow server, or the network connection between the two is fast (say on same LAN), there's little problem here, even with the fairly-extensive MLFlow database I run in my workplace. However, when the systems running Vim and the MLFlow server are separated by a slower or less consistent network connection (e.g. running Vim on a machine at home connecting to MLFlow server at work), then things can be excruciatingly slow. It's all down to the speed of your database server and of your network access from your Vim process to that database server. There's no question this should be revamped and taken care of, and it will, but meanwhile the thing is fully functional in this fairly common use-case, and highly configurable in terms of layout, syntax coloring, and so on.
See its Github repo for more detail, but in general you just enter vim-mlflow mode in your Vim session, browse around among different experiments and runs in the sidebar, mark runs of interest, and then view those marked runs together (including from different experiments) in the Marked Runs buffer in which one can further filter columns and contents to compare the runs.