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
Currently store settings are passed as query params, mapping the name of settings to strings that are encoded in the same way as nix.conf.
There are two things I don't like about this:
I don't like supporting arrays by splitting on spaces, that makes it impossible to have an array element that is a string maintaining a space.
I would like to move all the config code down to libmain, but if libstore relies on that (since store URL parsing, or at least StoreReference -> Store, probably should continue to live in libstore) then the config stuff can at most move from libutil to libstore.
A possible solution to get more structured information in the query param is as follows:
A single ?__json=<percent-encoded-json> that is less good for humans, but easier for machines, as a complement to 2 and 3.
Supporting this in addition I think is definitely desirable, the real question is can we just support this, and immediately get rid of the old space-splitting logic, or would that be too big a breaking change?
Impact analysis
Here is a way to get the list of settings, bucketed by type
since you suggest a revamp, might be the opportunity to name/alias the builder #2766. So far I use shell variables that I pass to --option builders "$BUILDER1". The space delimiter was not convenient when defining the alias.
Currently store settings are passed as query params, mapping the name of settings to strings that are encoded in the same way as
nix.conf
.There are two things I don't like about this:
libmain
, but iflibstore
relies on that (since store URL parsing, or at leastStoreReference
-> Store, probably should continue to live in
libstore) then the config stuff can at most move from
libutilto libstore
.A possible solution to get more structured information in the query param is as follows:
tag[]=...
as described in https://stackoverflow.com/questions/6243051/how-to-pass-an-array-within-a-query-string as a common idiom many web frameworks support (unfortunately not all in the same way). See also https://angular.io/api/common/http/HttpParamsOptions#fromObject. This gets us at least tostd::map<std::string, std::string | std::vector<std::string>>
, as long as no key contains[]
foo.bar=
flattening for nested objects, see also https://stackoverflow.com/questions/15872658/standardized-way-to-serialize-json-to-query-string. That gets usstd::map<std::string, nlohmann::json>
as long as no key contains.
or[]
.?__json=<percent-encoded-json>
that is less good for humans, but easier for machines, as a complement to 2 and 3.Supporting this in addition I think is definitely desirable, the real question is can we just support this, and immediately get rid of the old space-splitting logic, or would that be too big a breaking change?
Impact analysis
Here is a way to get the list of settings, bucketed by type
Currently, that gives:
What this says is:
Already matches JSON encodings:
bool
(bool)std::string
/ Path` (string)uint64_t
/unsigned int
/int
(number)Doesn't match, because array split
Strings
/StringSet
(array of strings)The latter types are used by these settings:
remoteProgram
systemFeatures
The text was updated successfully, but these errors were encountered: