dpleban

Great to see DVC being discussed here! As a tool, it’s done a lot to simplify version control for data and models, and it’s been a game-changer for many in the MLOps space.

Specifically, it's a genius way to store large files in git repos directly on any object storage without custom application servers like git-lfs or rewriting git from scratch...

At DagsHub [0], we've integrated directly with DVC for a looong time, so teams can use it with added features like visualizing and labeling datasets managing and models, running experiments collaboratively, and tracking everything (code, data, models, etc.) all in one place.

Just wanted to share that for those already using or considering DVC—there are some options to use it as a building block in a more end-to-end toolchain.

[0] https://dagshub.com

This is a truly incredible piece interviewing a bunch of leading ML companies on how they get their models to the real world. Lots of great insights

Hi HN! I'm one of the creators of DagsHub - and we're excited to be sharing this with you today.

As Data Scientists, we sometimes have interactive outputs from Jupyter notebook cells. Up to now, most places you'd save notebooks, e.g. GitHub/GitLab, only showed a static image instead of the original rich output, and you'd have to open the notebook in Colab, or a similar tool in order to interact with your outputs.

This limits sharability and creates a lossy experience.

We wanted to fix this, so now when you commit a notebook to DagsHub (or connect a GitHub project with such a notebook), you see the interactive outputs as they should be – interactive.

This means that things like EDA and dashboarding tools are much cooler and more useful.

Oh, and you don't need to change your code or download or import anything.

It has relied on the ability to make predictions based on pusblished theories, methods, laws etc

This might be a semantic argument, but what you describe is replication. Imagine every scientist would say "In my experiment, I perfectly predicted this and that, oh but no one else would ever be able to run that experiment again, so just trust me, ok?"

Replication/reproducibility isn't about logging every configuration, machine or particle. It's about being able to run the same method and get the same result. If that isn't the case, how do we know the predictions are correct?

This looks really cool.

Also, thanks! I just discovered unDraw thanks to this!

The idea of writing a commit message in advance is nice, and possibly helpful in focusing, but I don't understand the added value with respect to the issue stated. Commit messages aren't the challenge, rather it is planning out what goes into a commit.

As many others have said there are already great UIs to help you manage these things retroactively, but there is probably no good substitute to properly planning your work and executing on that plan (if order is your top priority)

Please don't turn it into another Microsoft Teams.