- rename fields so they are meaningful (this is a leftover
from it inheriting std::pair)
- add environment list member
- add constructor that consumes a QVariantMap
The difference wasn't being recorded in the ABI-parts of
the CalamaresConfig.h header file, and it was unclear if
the two builds were "clean", e.g. no pybind11 stuff in a
boost build and vice-versa.
Tidy that up by writing more ABI info to the header and
double-checking defines when including Python-related
Calamares headers.
While tempting, none of the STL containers are intended
for inheritance, and there's risks of slicing when used
as value types. Make InstanceKey a regular value type
data class and add the few operators that we actually
used from std::pair by hand.
Do not rely on Q_DECL_EXPORT and the like. Since we support basically
only gcc and clang for the kinds of Linux targets Calamares gets used
on, use visibility-specifiers that those compilers understand.
When running a command in the chroot, don't set TMP (and similar)
variables because those directories might nog make sense in the
target (yet).
FIXES#2269
Use case would be customization of default modules, eg packagechooser requires compat/Variant.h and packages/Globals.h to compile in the calamares-extension repo
Signed-off-by: artoo <artoo@artixlinux.org>
All unknown-variants return None, but this only
happens in practice with an empty variant (e.g.
a configuration key that is empty in the YAML).
FIXES#2237
While this isn't useful in production, it makes tests a lot
simpler to write since you don't have to wrestle with
creating new GS objects in order to start fresh.
From inside Calamares, register libcalamares to the
interpreter by hand; from external Python processes
the regular extension library hooks are called.
Tested by running ./build/localmodule dummypython
(which means that the shared library is not present
in the current directory, so then `import libcalamares`
fails if the module is not already registered --
a test scenario that previous attempt at module
import missed).
bqi is one possible name of Luri / Lhur language,
as far as I can tell -- there is also Northern Luri,
which is supported by Qt and has code lrc.
ie is Interlingue, which Qt maps to C locale.
Work around that by mapping it to interlingua.
The Calamares Manager should not be a singleton; it is needed
in multiple threads (e.g. from QML). It can have a singleton
Private manager that caches and shares things, though.
