Kiara

Latest version: v0.5.9

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

Scan your dependencies

Page 3 of 5

0.1.0

- first 'official' release on Pypi.org
- the code and its API in this release can by no means be considered stable, but the largest pieces of its architecture should be in place by now
- there are still some refactorings to be made, and lots of features to implement, but this version should be good enough to do some very basic processing and data management

0.0.15

- support for saving values of type string, integer, float, bool
- some CI improvements when a tag is pushed: release to PyPi, auto-create versioned documentation

0.0.14

- this version contains a rather large refactoring of the data registry and how values are handled, so expect some breakage. Please submit issues for anything that worked, but doesn't anymore. Also, you'll have to delete the kiara shared local data (`~/.local/share/kiara` on linux) when upgrading.
- renamed:
- kiara.pipeline.config.PipelineModuleConfig -> kiara.pipeline.config.PipelineConfig
- kiara.module_config.ModuleTypeConfig -> kiara.module_config.KiaraModuleConfig
- kiara.module_config.ModuleConfig -> kiara.module_config.ModuleConfig
- in kiara.pipeline.values:
- StepInputField -> StepInputRef
- StepOutputField -> StepOutputRef
- PipelineInputField -> PipelineInputRef
- PipelineOutputField -> PipelineOutputRef
- kiara.pipeline.values -> kiara.data.registry:
- ValueField -> ValueRef
- PipelineValue -> removed
- DataValue -> removed
- LinkedValue -> removed
- ValueUpdateHandler -> ValueUpdateHandler
- kiara.data.values.ValueMap*-related -> kiara.data.values.value_set
- removed 'pipeline_id' attribute from 'PipelineStructure' class, but 'Pipeline" has 'id' and 'title' fields now instead
- refactored 'DataRegistry' and 'Value' object:
- 'Value' objects are now immutable, and can only be created via a registry
- all subclasses of 'Value' are removed, there is only one 'Value' type now, which is always connected to a data registry (which handles versioning and actual storage of the payload)
- removed linked values, replaced by 'ValueSlot' class
- 'ValueSlot' basically contains the history of all (immutable) Value objects on a specific spot (mostly within a pipeline, but can be used elsewhere)
- 'set_value_data' on 'Value' class is removed (since values are no immutable)
- the interface of 'ValueMap' however is mostly unchanged, and all 'set/get value_obj/value_data' methods should still work as before
- data store is now just a 'DataRegistry' subclass that persists to disk instead of memory, this means that getting data into the data store now uses the 'register_data' method, and getting it out uses 'get_value_obj'
- aliases can now only contain alphanumeric characters, '_' and '-"
- removed some data import modules/operations until I settled on a data onboarding strategy (current one was leaky). This is mostly relevant for the operation that imports a table from a (path) string -- use a mini-pipeline as replacement and save the table manually, something like: https://github.com/DHARPA-Project/kiara/blob/main/tests/resources/pipelines/table_import.json
- rudimentary data lineage support
- performance improvement for cli, because more stuff is now lazily loaded
- tests

0.0.13

- mostly tests

0.0.12

- renamed:
- kiara.operations.OperationConfig -> kiara.operations.Operation
- kiara.operations.Operations -> kiara.operations.OperationType
- re-organizing/re-naming of onboarding/import related module/operation names
- small change to how job control works in the pipeline-controller:
- calling the `wait_for` job-ids method is now mandatory after calling the `process_step` method, even when using the synchronous non-parallel processor
- because the `wait_for` method now comes with an argument `sync_outputs` (default: True) that allows not actually syncing the output of the processing step to the pipeline value (which gives the controller more control over when to do that)
- if you were calling `wait_for` before, there is nothing more to do. If you used the synchronous (default) processor and omitted that step, you'll have to add a line below your `process_step` call, `wait_for`-ing for the job ids that method returned
- re-implementation/refactoring of operations (documentation still to be done)
- removed 'kiara.module.ModuleInfo' class (use 'kiara.metadata.module_models.ModuleTypeInfo' instead)
- refactorings:
- kiara.pipeline.module.PipelineModuleInfo -> kiara.info.pipelines.PipelineModuleInfo
- other renames/relocations of (hopefully) mostly internal classes -- if something is missing it should now be somewhere under 'kiara.info.*'
- renamed subcommand 'pipeline structure' -> 'pipeline explain'

0.0.11

- added 'BatchControllerManual' controller

Page 3 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.