-
Notifications
You must be signed in to change notification settings - Fork 12
Conversation
Link Check ReportAll 3 links passed! |
less hacky than https://github.com/tqdm/tqdm/blob/master/.meta/mkdocs.py :) |
arguments: | ||
MODEL Path to model [required] | ||
[SUBTYPE] Type of build. Choices: ['whl', 'pip', 'docker_dir', 'docker'] | ||
Builtin builders: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MODEL -> model
required / optional check how it's done in other docs
list with options - it was better the way it was done (compact, easier to read, etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
required and optional are different things: required means you always should provide it, optional means it can have None
value. Required optional means you will get error if you don't provide it, but you can set it to None
. Not required not optional means there is a default value which is not None
and you can't set it to None
also cli changed a bit, now mlem build *
are subcommands (instead of argument). Also mlem build
is a separate command (for building from saved config using -l
). I will update this soon when I decide how to better reflect this (same with serve
and apply-remote
)
|
||
## Options | ||
|
||
- `-p, --project TEXT`: Path to MLEM project [default: (none)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style: -p <path>
, --project <path>
- path to MLEM ...
default - check how it's done in the docs
TEXT should be renamed into path, also in the CLI itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, but sometimes the duplication of metavar feels strange
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few misc. Qs below.
I like the intent but I'm a bit skeptical about actually applying this as a process. Curious to see how it goes though, happy to help if I can. Lmk!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the automation effort is always great and this particular PR is def. an improvement and quite mergeable (after removing script and auxiliary files). Some minor comments below, but I'm not blocking it.
I'm not sure that we can continue to use this specific script though, maybe start only with overwriting usage blocks.
Cc @omesser FYI (rel. #171 (comment))
|
||
## Examples |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for these lines when there are no examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I added this to not forget to add them :)
List [MLEM objects](/doc/user-guide/basic-concepts#mlem-objects) inside a MLEM | ||
project (location should be [initialized](/doc/command-reference/init)). | ||
|
||
> Aliased to `mlem ls` | ||
List MLEM objects inside a [MLEM project](/doc/user-guide/project-structure). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're losing a link and the alias note here.
# serve | ||
|
||
Locally deploy the model using a server implementation and expose its methods as | ||
endpoints. | ||
Create an API from model methods using a server implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previous version may be better? (would need core change)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed this because you commented on core repo PR :) So should I return old doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't remember the context. Can you link to the discussion? Up to you though, thanks.
I'd say lets merge this! I created a separate |
This is a list of activities that should be done before release announce ## First, things before release ### Breaking changes - merge in this PR - [x] New deployment state management - [x] New CLI interface: breaking changes in `serve`, `apply-remote`, `build` and `declare` ### Other changes - merge in this PR - [x] SageMaker deployments - [x] K8s deployments - [x] `--quiet` #448 @mike0sv ### Docs - [x] Finish semi-generated API reference PR iterative/mlem.ai#172 - [x] Update Quick Start in this repo - [x] iterative/mlem.ai#197 - [ ] iterative/mlem.ai#188 ### Blog post - [ ] blog post re release @aguschin ### Example-repo - PR in `example-repos-dev` - [x] update `example-mlem-get-started` ### Update the website code animations - [x] https://mlem.ai ## Second, the release itself ### MLEM Release - [ ] merge this branch - [ ] release it on PyPi - [ ] merge docs PR - [ ] merge PR in `example-repos-dev` and update `iterative/example-mlem-get-started` ## Third, things after release - [ ] remove `xfail` mark from `tests/cli/test_mail.py::test_commands_docs_links`
First step for #171
This PR contains auto-generation machinery for CLI reference.
_generate_cli_spec.py
generatesspec.json
file frommlem.cli.app
object_generate_options.py
readsspec.json
and for each command generates sections and inserts them into respective .md filesAuto-generated sections:
There are also 2 not generated sections: Description and Examples.
Example: suppose we have a key in
spec.json
And apply.md
It will be transformed in place into:
Feel free to suggest changes to generated content formatting and to spec schema