You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 13, 2023. It is now read-only.
A bug in the tutorial. I copy-paste it step by step.
>>> save(rf, "models/rf", sample_data=df)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'df' is not defined. Did you mean: 'rf'?
Why is it called data? Shouldn't it be model? If the type is unknown - something else.
save(rf, "mlem-m", sample_data=data) returns (and prints in iPython) a massive object. It does not look good. Wouldn't it be better to suppress printing? Like model = save(...)
In model.mlem - is there any chance to make a single list of params instead of two lists of names and types?
name: predict - isn't it duplication with predict from the above:
methods:
predict: # <--- this predictargs:
- name: Xtype_:
# ....name: predict # <--- isn't it the same predict?
Is underscore really needed in type_?
Can be null just skipped by default?
shape:
- null
Another workflow bug - pd were never imported
>>> df = pd.DataFrame([[0, 1, 2, 3]], columns=features)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'pd' is not defined. Did you mean: 'id'?
Workflow missmatch - first scrips were considered interactive (train.py and saving models script with no name) while predict.py is running from CLI. It confuses user. Is it possible to make it fully interactive and working end-to-end? Clarification - it's ok to run CLI command in special cases like running mlem commands but not python.
Making requests section - a curl command example can be a better rather than a link to Swagger UI
Docker deployment bug:
$ mlem deployment run docker_container docker_app.mlem \
> --model models/rf \
> --image_name mlem-rf-server \
> --server fastapi
Usage: mlem deployment run docker_container path
Try 'mlem deployment run docker_container -h' for help.
╭─ Error ───────────────────────────────────────────────────────────────────────────────────╮
│ No such option: --image_name (Possible options: --container_name, --image.name, │
│ --image.tag) │
╰───────────────────────────────────────────────────────────────────────────────────────────╯
Docker deployment error formatting - error output is not standard for CLI. The value of the frame is not clear but it takes quite a bit of space.
╭─ Error ───────────────────────────────────────────────────────────────────────────────────╮
│ No such option: --image_name (Possible options: --container_name, --image.name, │
│ --image.tag) │
╰───────────────────────────────────────────────────────────────────────────────────────────╯
--image.name, --image.tag etc - not standard CLI notation for parameters. It has to be --image-name
Prefix-Emoji in error messages and warning are not a good practice in CLI - ❌ Error calling docker:.
data
? Shouldn't it bemodel
? If the type is unknown - something else.save(rf, "mlem-m", sample_data=data)
returns (and prints in iPython) a massive object. It does not look good. Wouldn't it be better to suppress printing? Likemodel = save(...)
name: predict
- isn't it duplication withpredict
from the above:type_
?pd
were never importedWorkflow missmatch - first scrips were considered interactive (
train.py
and saving models script with no name) whilepredict.py
is running from CLI. It confuses user. Is it possible to make it fully interactive and working end-to-end? Clarification - it's ok to run CLI command in special cases like runningmlem
commands but not python.Making requests
section - acurl
command example can be a better rather than a link to Swagger UIDocker deployment bug:
--image.name
,--image.tag
etc - not standard CLI notation for parameters. It has to be--image-name
Prefix-Emoji in error messages and warning are not a good practice in CLI -
❌ Error calling docker:
.It is saying that docker is running but there is nothing in https://localhost:8080/docs Bug?
--json
option, it does not change the output. See example above.The text was updated successfully, but these errors were encountered: