Version 3.3.0 - Python Import Inject

Added

• A new expression for injecting values imported from/via Python like so
  ${__PY__:alviss.__version__}
  • This uses the ccptools.tpu.strimp.get_any(...) to import whatever the
    expression key points to and inject into the parsed config
  • The use case here is mainly to inject dynamic Python values into Alviss
    files "on-demand" like when using ccp-stencil
    templates in a CI/CD pipe so you can have the ever-changing version of the
    package you're working on injected automatically into the Alviss config file
    used as Context for rendering Docker files, Kube manifests and so on
    (similar to how it can be done in pyproject.toml)
  • This expression also adheres to the normal format of "defaults" (e.g.
    ${__PY__:alviss.__version__=Unknown}) and "required" (e.g.
    ${__PY__:alviss.__version__!=})

Version 3.2.2 - Stubber fixe

Fixed

• Stubber CLI was ignoring the class name when using the -o output flag

Version 3.2.1 - Stubber changes and fixes

Changed

• Stubber now has an option to only "export" the resulting "Final" stub
  class and keeping all the other stubs "private" and this option is True by
  default (they don't really need to be public)
• You can now give the resulting "Final" config stub a custom name
• You can also give the "Final" config stub an empty string for a name which
  will simply omit generating it (for custom/complex composition of stubs
  later on if people want)
• All stubs now also inherit from dict because any attribute in
  BaseConfig that's a Map (and thus has a stub class) will also behave as
  a dict (even if Empty)

Fixed

• Stubber now appends an underscore to stubs with Python reserved keywords
  like class and def etc.
• The BaseConfig object now also spots attribute fetching of those
  keywords with an appended underscore and fetches the correct attribute
  nevertheless.

Version 3.2.0 - Stubber Update

Version 3.2.0 - Stubber Update

Added

• Stub generators from descriptor config files where you structure out your
  config file and give each value the Python type you expect the config to
  yield in order to generate type-hinting stub-classes that match the structure
  of your config file(s).
• CLI commands for running the stub generation: alviss-stubber
• CLI commands for running the config rendering: alviss-render
• A bunch of Alviss specific Error Exceptions that are raised e.g.
  when files aren't found or when Fidelius is required but isn't installed

Changed

• The rendering of static single file configs from Alviss config files and
  expressions has now been moved into its own sub-module with a standard API

Version 3.1.0 - Required Env Vars

Version 3.1.0 - Required Env Vars

Added

• A way to make evaluating environment variables require a value to be found by
  appending != to the end of the expression like so ${__ENV__:API_KEY!=}.
  Missing values will trigger a ValueError raised when loading config files.

Version 3.0.0 - Fidelius Seperation & Tests

Version 3.0.0 - Fidelius Separation & Tests

Note: This is the first Github release and it was accidentally left in "draft", thus it's incorrectly ordered, shoved in between 3.2.0 and 3.2.1.

Added

• Fidelius mode - Alviss now reads the ALVISS_FIDELIUS_MODE environment
  variable to determine one of these Fidelius modes available:
  • ON_DEMAND (default): Fidelius is only ever loaded (i.e. an import is
    attempted) if fidelius expressions (__FID__) are encountered when reading
    a config
  • ENABLED: Alviss tries to import fidelius on startup and raises an
    ImportError if it fails
  • DISABLED: All fidelius expressions (__FID__) are simply ignored and
    left unparsed
  • SUBSTITUTE_ENV: All fidelius expressions (__FID__) are treated as if
    they are environment variable expressions (__ENV__)
  • MOCK: Fidelius will be initialised using its mock implementation,
    which uses a singleton in-memory datastore, making this useful for testing
• Error reporting on the keys that have Fidelius tags in them in case of a
  Fidelius related error (like access problems or if fidelius is not installed)
• Fidelius can now grab config values from the config files Alviss is
  reading via the __fidelius__ special key (e.g. ALVISS_FIDELIUS_MODE
  and any kwargs that AwsParamStoreRepo takes.

Changed

• Migrated the project from our internal repos to Github and Pypi
• Alviss now ships by default without fidelius
  support and runs in ALVISS_FIDELIUS_MODE=ON_DEMAND and this only tries
  to import fidelius if a __FID__ expression is encountered
  • Installing Alviss with built in fidelius support can still be done via
    pip install alviss[fidelius] plus all the boto3 stuff and such
• Bumped the fidelius version to 1.0.0 so now all the new environment
  variables available in that version can be used to configure fidelius in
  Alviss, e.g. by setting FIDELIUS_AWS_ENDPOINT_URL to point to a
  LocalStack container for testing
  and/or development.

Fixed

• An issue where the default values of environment variables could not
  contain any whitespaces (like a simple space)