Kiara

Latest version: v0.5.10

Safety actively analyzes 619482 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 5

0.5.10

- archive export & import feature:
- new cli subcommands:
- `kiara archive import`
- `kiara archive export`
- `kiara archive explain`
- `kiara data import`
- `kiara data export`
- new api endpoints:
- `retrieve_archive_info`
- `export_archive`
- `import_archive`
- `export_values`
- `import_values`
- always store every job record and job result value(s)
- allow a 'comment' to be associated with a job:
- require a 'comment' for every `run_job`/`queue_job` call
- new job record api endpoints:
- `list_all_job_record_ids`
- `list_job_record_ids`
- `list_all_job_records`
- `list_job_records`
- `get_job_record`
- `get_job_comment`
- `set_job_comment`
- add convenience api endpoint `get_values`
- improved input options for 'store_values' API endpoint
- added 'value_created' property on 'Value' instances
- add '--runtime-info' cli flag to display runtime folders/files used by *kiara*
- fix: plugin info for plugins with '-' in name
- moved `KiaraAPI` class to `kiara.interfaces.python_api.kiara_api` module (the 'offical' import path `kiara.api.KiaraAPI` is still available, and should be used)
- have `KiaraAPI` proxy a `BaseAPI` class, to make it easier to extend the API and keep it stable

0.5.9

- mostly test coverage improvements
- fix: support alias prefixed strings as job inputs

0.5.8

- add 'mock' module type

0.5.5

- added pipeline related api endpoints:
- `list_pipeline_ids`
- `list_pipelines`
- `get_pipeline`
- `retrieve_pipeline_info`
- 'retrieve_pipelines_info'

- added support for quering plugin information
- cli: `kiara info plugin`
- api endpoints:
- `list_available_plugin_names`
- `retrieve_plugin_info`
- `retrieve_plugin_infos`

0.3.1

- allow 'dict' field name

0.3.0

- changed metadata format of stored value metadata: data store must be cleared when updating to this version
- refactoring of operation type input names -- this replaces most instances where the input name was 'value_item' (or similar). I've decided that using the value type as input name increases usability of those operations more than the costs associated with having different input names for operations of the same type, for example:
- pretty_print: 'value_item' -> type name of the value to pretty print
- extract_metadata: 'value_item' -> type name of the value to extract metadata from
- import: 'source' input -> input file type, 'value_item' output -> target file type
- save_value: 'value_item' input -> file type of value to save
- convert (renamed to 'create'): value_item to source profile and target type

Page 1 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.