Kiara

Latest version: v0.5.11

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

Scan your dependencies

Page 4 of 5

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

0.0.10

- major refactoring:
- renamed:
- 'kiara.module_config.KiaraWorkflowConfig' -> 'kiara.module_config.ModuleConfig'
- 'kiara.module_config.KiaraModuleConfig' -> 'kiara.module_config.KiaraModuleConfig'
- moved classes/functions:
- 'kiara.data.operations' -> 'kiara.operations.type_operations'
- 'kiara.processing.ModuleProcessor' -> 'kiara.processing.processor.ModuleProcessor'
- from 'kiara.module_config' -> kiara.pipeline.utils:
- create_step_value_address
- ensure_step_value_addresses
- from 'kiara.module_config' -> kiara.pipeline.config:
- PipelineStepConfig
- PipelineStructureConfig
- PipelineConfig
- from 'kiara.data.values' -> 'kiara.pipeline.utils':
- generate_step_alias
- from 'kiara.data.values' -> 'kiara.pipeline'
- PipelineValueInfo
- PipelineValuesInfo
- from 'kiara.data.values' -> 'kiara.pipeline.values'
- ValueUpdateHandler
- StepValueAddress
- ValueRef
- RegisteredValue
- RegisteredValue
- LinkedValue
- StepInputRef
- StepOutputRef
- PipelineInputRef
- PipelineOutputRef

0.0.9

- removed 'aliases' attribute from Value class, aliases are now specified when calling 'save' on the Value object
- ActiveJob details (incl. error messages -- check the kiara.processing.ActiveJob class) for the most recent or current module executions can be retrieved: `[controller_obj].get_job_details(step_id)
- re-write of the DataStore class:
- support for aliases, as well as alias versions & tags (still to be documented)
- enables the option of having different data store types down the line
- API and overall workings of this is still a draft, so expect to see some changes to how value ids and alias are handled and look like
- internal organisation of existing data is different, so when updating to this version you'll have to re-import your data sets and ideally also delete the old folder (``DEVELOP=true kiara data clear-data-store``)
- '--save' option in the ``kiara run`` command does now take an alias as option (previously the '--alias` flag)

0.0.6

- housekeeping

0.0.5

- this is only a stop-gap release, to a) test the release pipeline, and b) prepare for a fairly major doc/testing effort in the next few weeks
- introduced data operations: operation do the same thing to values of different types (pretty printing, serializing, etc.)

Page 4 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.