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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
StringSchema::check_constraint runs `parse_property_string` for
property strings, but when we deserialize a `PropertyString` we
immediately follow that up with deserializing it using the schema, so
there's no need to check it beforehand.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This provides `proxmox_schema::property_string::PropertyString<T>` for
a typed property-string.
To facilitate this, this introduces
`proxmox_schema:🇩🇪:SchemaDeserializer` which is a serde deserializer
for property strings given a schema.
This basically maps to one of `de::SeqAccess` (for array schemas) or
`de::MapAccess` (for object schemas).
Additionally, a `de::NoSchemaDeserializer` is added, since properties
within the strings may have string schemas with no format to it, while
the type we serialize to may ask for an array (a simple "list") via
serde.
The deserializers support borrowing, for which a helper `Cow3` needed
to be added, since property strings support quoting with escape
sequences where an intermediate string would be allocated and with an
intermediate lifetime distinct from the `'de` lifetime.
A `de::verify` module is added which uses serde infrastructure to
validate schemas without first having to deserialize a complete
`serde_json::Value`.
For serialization, `proxmox_schema::ser::PropertyStringSerializer` is
added split into similar parts `ser::SerializeStruct` and
`ser::SerializeSeq` at the top level, and the same prefixed with
`Element` for inside the actual string. This should also properly
quote the contents if required.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
it's the version currently shipped by bookworm, so let's unify this widely-used
dependency to make bootstrapping easier.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
so that we no longer have to (or forget to) bump the version in multiple places.
notable changes:
- outdated versions have been unified
- proxmox-metrics -> proxmox-async no longer uses explicit empty features
(proxmox-async doesn't provide any anyway)
- proxmox-subscription -> proxmox-http no longer uses explicit default_features
= false (proxmox-http has an empty default feature anyway)
- missing path dependencies added (mainly proxmox-rest-server)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
noteworthy changes:
- proxmox-http had a default_features_false dep on hyper, which is dropped (the
default feature is empty anyway)
- hyper, libc, nix, tokio and url versions are unified
- missing (cosmetic) bindgen feature on zstd enabled everywhere
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to reduce the creep of optional dependencies being exposed as features.
this requires cargo 0.63 (and debcargo built against at least that
version), but greatly reduces the number of binary packages and provides
generated, while still allowing sensible selection of optional
dependencies via the explicit feature meant for pulling them in.
diff stat for running `make deb` after this change:
proxmox-http/debian/control | 226 ++++--------------------------------
proxmox-router/debian/control | 74 +-----------
proxmox-schema/debian/control | 53 ++-------
proxmox-subscription/debian/control | 17 +--
proxmox-sys/debian/control | 51 +++-----
proxmox-tfa/debian/control | 110 ++----------------
6 files changed, 72 insertions(+), 459 deletions(-)
the 'dep:' prefix marks something on the RHS inside the features section
as dependency, it's only allowed if the string after it is an optional
dependency an no explicit feature of the same name exists. if all
pointers to the optional dependency in the features section are marked
as such, the optional dependency itself will not be exposed as a feature
(either on the cargo or debian/control level).
the '?' suffix marks dependencies as "weak", which only enables the
optional dependency + its feature(s) if the optional dependency itself
is also enabled. it has no effect on d/control since such a relationship
is not encodable in Debian package relations, but it does affect cargo
dependency resolution and allows skipping the build of unneeded optional
dependencies in some cases.
with no packages/crates depending on the no longer exposed automatically
generated features/packages, so these are safe to remove even though
it's technically a breaking change.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
with two variants:
(expr, expr) => assumes that the second is an 'Error'
(expr, (tt)+) => passes the tt through anyhow::format_err
also added tests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
'unwrap_' because they will panic and as `const fn` since
panic in const fn is now possible
Note that const evaluation will only be triggered when
actually used in const context, so to ensure *compile time*
checks, use something like this:
const FOO_SCHEMA: &AllOfSchema =
SomeType::API_SCHEMA.unwrap_all_of_schema();
then_use(FOO_SCHEMA);
or to use the list of enum values of an enum string type
with compile time checks:
const LIST: &'static [EnumEntry] =
AnEnumStringType::API_SCHEMA
.unwrap_string_schema()
.unwrap_format()
.unwrap_enum_format();
for values in LIST {
...
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This allows free form text to exist within property strings,
quoted, like:
key="A value with \"quotes, also commas",key2=value2
or also:
"the value for a default_key",key2=value2
And drop ';' as a key=value separator since those are meant
for arrays inside property strings...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
for ease of use implement these traits for ParameterError:
* From<(&str, Error)>
* From<(String, Error)>
* Extend<(String, Error)>
* Extend<(&str, Error)>
* IntoIterator<Item = (String, Error)>
and add the following methods:
* fn into_inner(self) -> Vec<(String, Error)>;
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
by replacing the whole Vec.
if we ever want to support adding/removing/modifying elements of a Vec
via the Updater, we'd need to extend it anyway (or use a custom
updater).
Suggested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
