keepsake
keepsake copied to clipboard
replicate
Version control for machine learning
Currently the release depends on us being able to push directly to main, which is error-prone. Let's figure out something better.
Copying files to temporary directories before upload is still synchronous, and with huge files this can take a lot of time. It's also possible that those huge files are included...
... and `google.rpc` and `google.protobuf`. Maybe some of this we can get rid of if we implement ourselves? There are some reasonably promising pure-Python GRPC implementations: - https://github.com/vmagamedov/grpclib - https://github.com/standy66/purerpc...
It shouldn't have to do this. It only needs to read `repository.json` then write new data.
From this discussion: https://github.com/replicate/replicate/pull/408#discussion_r551705523 If a future repository gets updated while an experiment is running (i.e. `version` in `repository.json` gets updated), then that experiment might break the repository. Maybe checkpoints...
`CheckoutCheckpoint` on the `Project` Go struct current serves two purposes: - Check out a checkpoint for Python API - Check out an experiment or checkpoint for CLI There should be...
Currently in a comment here: https://github.com/replicate/replicate/blob/main/proto/Makefile We should also document some higher-level stuff here -- how the GPRC daemon works, how to modify both Go and Python interface, etc. Follow-on...
When experiments are created, the metadata is created first and the data is uploaded second. This will cause failure when you try to check it out, because data doesn't exist...
# Why Replicate current displays when it is starting to upload things to the background. This is useful so you can understand what Replicate is doing, and so you can...
# Why If it takes a while, it looks like it's hanging and broken. # How This might be an excuse to try out https://github.com/mitchellh/go-glint # Related #475