Closed stellasphere closed 1 month ago
Thanks @LinasKo !
What I cannot evaluate is whether prior behavior, creating the
model
object without a matching model on the api, is valid use case somewhere.
I strongly believe that creating a model object when there is no model present is invalid behavior because the object it creates, a child of an InferenceModel
, and its methods predict
and load_model
will fail because it doesn't exist. Doing so also makes it impossible to determine from the package that a model does or does not exist.
One other request: there's a test.py
, which I think was included by accident.
One other request: there's a test.py
, which I think was included by accident.
Yup, I need to revoke my key too. Thanks for catching!
Sorry, fixed a failing test. @LinasKo can you re-approve?
M'afraid test.py snuck its way into the commit again :wink:
What I'm seeing is - the model may not exist, but that's valid only in a project version where it's not been trained yet. Is that right?
M'afraid test.py snuck its way into the commit again 😉
🤦 You would think i would learn, but no.
the model may not exist, but that's valid only in a project version where it's not been trained yet. Is that right?
Yes, where it's not been trained. (or uploaded, but the same thing)
Description
There should be no instance where
version.model
should return a model type class when there is no valid model present.Fixing this issue: https://roboflow.slack.com/archives/C056ZUJPK08/p1719359598748219
Type of change
Please delete options that are not relevant.
How has this change been tested, please provide a testcase or example of how you tested the change?
Locally and here: https://colab.research.google.com/drive/1rnYv49x4oVWt--O3alw2wg6pr2qNapEO?usp=sharing
Any specific deployment considerations
For example, documentation changes, usability, usage/costs, secrets, etc.
Docs