IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Drop #!feature(specialization) in favor of having a `cli`
property for types to decide whether they are CLI
compatible.
The unconstrained_type! macro now has both ParseCli and
ParseCliFromStr in view, and requires one of the two to be
implemented for a type. This means that if a type implements
FromStr, it should "just work".
For types created without the help of the #[api] macro,
there's a shortcut to exclude a type from the CLI via
the no_cli_type!{typename} macro.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
In order to get parameters from the command line into the
API we need to get them into a json value, so that we can
pass it down the handler which deserializes them into their
real type and runs verifications.
For this we need to define how the type is going to be
converted into a json Value. We cannot simply use
Deserialize as that would for instance require quotes
around strings. So instead, we have a ParseCli trait, which
is a nop (direct serde_json::Value::String()) for string
types, and uses .parse() (the std::str::FromStr trait) for
everything else.
Currently this uses a `default fn` as an example of the
specialization feature, but I'll probably remove this and
use yet another mass-impl macro since there isn't much
activity on that feature's issue tracker. (The issue itself
seems to be outdated ...
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
The CLI part itself needs much less info now as we'll take
as much as we can from the api methods themselves. Note that
we may still want to be able to add extra info to a cli
command in particular, for instance, for the completion
callbacks. For now this is all part of the method itself.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
while filling the Parameter fields as &'static we cannot
really make use of the get_type_info() yet because it would
need to be a `const fn` (possible via #!feature(const_fn)),
so for now we store the method pointer until `const_fn` is
stable
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This should support arbitrary expresion, so gobble up
elements up to the next comma and then run it through
syn::parse2.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
TODO:
- change parse_object to use Punctuated for the fields to
support longer value types (so we can use actual types
as fields)
- allow adding a body type to methods
- allow adding a body type to routers explicitly
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Since we already know we'll want to be using hyper::Body and
bytes::Bytes as API output, we need to allow making routers
for each kind.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We'll have a separate router for the command line, so the
http router won't live in the root module.
It is still exported at the root level, though, via
proxmox::api::Router.
Also move ApiType into api_type.rs, makes more sense.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This contains the router and will get helpers for
generating documentation, and for parsing command line
parameters for api methods.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
