blobhub 0.2 is a rewrite, and it has no compatibility layer, because there is nothing left to stay compatible
with: 0.1.x cannot talk to the current API. Every ONNX command it builds carries an engine key that the API now
refuses with 400 invalid_request_body, and its revisions.latest() reads a revision listing that is now paged.
Upgrade, and pin the new line:
Call by call
What behaves differently
- The default revision, not the newest.
latest()took the newest revision;revision()takes the blob’s default. They are usually the same, because a new draft becomes the default. For the newest,next(blob.revisions()). - Credentials come from the usual places. A key passed to a constructor becomes
connect(api_key=…),BLOBHUB_API_KEY, or a profile stored byblobhub login. Public content needs no key at all:connect(anonymous=True). See Credentials and profiles. - An upload waits for its processing.
upload()returns once the platform has processed the model, and raisesOperationFailedif it could not. - Nothing is unpacked locally. 0.1.x downloaded the archive and extracted it. 0.2 downloads
model.onnx, which the platform already extracted, and the archive only when you ask formodel.tar.gz. - No size switches.
Config(force_multipart_upload=…, force_multipart_download=…)has no equivalent. A transfer above 4 MiB always moves in parts. - Writes are not repeated blindly. A write that fails in a way that may have reached the platform is raised, not retried. See Errors and retries.
Old downloads
0.1.x saved models under~/.blobhub/<blob id>/<revision id>/. 0.2 caches them under
~/.cache/blobhub/revisions/<revision id>/, and never reads or removes the old folders.
To get the space back, delete the per-blob folders by hand. Do not delete ~/.blobhub itself: it also holds
credentials.yaml, with the profiles blobhub-cli and blobhub-worker use, and blobhub-cli’s cache/.
Notebooks
The example notebooks now ship inside the package, rewritten for 0.2, andpython -m blobhub.notebooks copy <id> copies one out. See Notebooks.
