Metaflow

Latest version: v2.13

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

Scan your dependencies

Page 24 of 28

2.3.3

The Metaflow 2.3.3 release is a patch release.
- [Features](2.3.3_features)
- [Support resource tags for Metaflow's integration with AWS Batch](632)
- [Bug Fixes](2.3.3_bugs)
- [Properly handle `None` as defaults for parameters for AWS Step Functions execution](630)
- [Fix return value of `IncludeFile` artifacts](607)

<a name="v2.3.3_features"></a> Features
[Support resource tags for Metaflow's integration with AWS Batch](632)
Metaflow now supports setting [resource tags for AWS Batch jobs](https://docs.aws.amazon.com/batch/latest/userguide/using-tags.html) and propagating them to the underlying ECS tasks. The following tags are attached to the AWS Batch jobs now -
- `metaflow.flow_name`
- `metaflow.run_id`
- `metaflow.step_name`
- `metaflow.user` / `metaflow.owner`
- `metaflow.version`
- `metaflow.production_token`

To enable this feature, set the environment variable (or alternatively in the `metaflow config`) `METAFLOW_BATCH_EMIT_TAGS` to `True`. Keep in mind that the IAM role (`MetaflowUserRole`, `StepFunctionsRole`) submitting the jobs to AWS Batch will need to have the `Batch:TagResource` permission.

<a name="v2.3.3_bugs"></a> Bug Fixes
[Properly handle `None` as defaults for parameters for AWS Step Functions execution](630)
Prior to this release, a parameter specification like -

Parameter(name="test_param", type=int, default=None)

will result in an error even though the default has been specified

Flow failed:
The value of parameter test_param is ambiguous. It does not have a default and it is not required.

This release fixes this behavior by allowing the flow to execute as it would locally.

[Fix return value of `IncludeFile` artifacts](607)
The `IncludeFile` parameter would return JSONified metadata about the file rather than the file contents when accessed through the `Metaflow Client`. This release fixes that behavior by returning instead the file contents, just like any other Metaflow data artifact.

2.3.2

The Metaflow 2.3.2 release is a minor release.
- [Features](2.3.2_features)
- `step-functions trigger` command now supports `--run-id-file` option

<a name="v2.3.2_features"></a> Features
`step-functions trigger` command now supports `--run-id-file` option
Similar to `run` , you can now pass `--run-id-file` option to `step-function trigger`. Metaflow then will write the triggered run id to the specified file. This is useful if you have additional scripts that require the run id to examine the run or wait until it finishes.

2.3.1

The Metaflow 2.3.1 release is a minor release.
- [Features](2.3.1_features)
- [Performance optimizations for `merge_artifacts`](556)

<a name="v2.3.1_features"></a> Features
[Performance optimizations for `merge_artifacts`](556)
Prior to this release, `FlowSpec.merge_artifacts` was loading all of the merged artifacts into memory after doing all of the consistency checks with hashes. This release now avoids the memory and compute costs of decompressing, de-pickling, re-pickling, and recompressing each merged artifact - resulting in improved performance of `merge_artifacts`.

2.3.0

The Metaflow 2.3.0 release is a minor release.
- [Features](2.3.0_features)
- [Coordinate larger Metaflow projects with `project`](https://docs.metaflow.org/going-to-production-with-metaflow/coordinating-larger-metaflow-projects)
- [Hyphenated-parameters support in AWS Step Functions](539)
- [State Machine execution history logging for AWS Step Functions in AWS CloudWatch Logs](536)

<a name="v2.3.0_features"></a> Features
[Coordinate larger Metaflow projects with `project`](https://docs.metaflow.org/going-to-production-with-metaflow/coordinating-larger-metaflow-projects)
It's not uncommon for multiple people to work on the same workflow simultaneously. Metaflow makes it possible by keeping executions [isolated through independently stored artifacts and namespaces](https://docs.metaflow.org/metaflow/tagging). However, by default, [all AWS Step Functions deployments](https://docs.metaflow.org/going-to-production-with-metaflow/scheduling-metaflow-flows) are bound to the name of the workflow. If multiple people call `step-functions create` independently, each deployment will overwrite the previous one.
In the early stages of a project, this simple model is convenient but as the project grows, it is desirable that multiple people can test their own AWS Step Functions deployments without interference. Or, as a single developer, you may want to experiment with multiple independent AWS Step Functions deployments of their workflow.
This release introduces a `project` decorator to address this need. The `project` decorator is used at the `FlowSpec`-level to bind a Flow to a specific project. All flows with the same project name belong to the same project.

from metaflow import FlowSpec, step, project, current

project(name='example_project')
class ProjectFlow(FlowSpec):

step
def start(self):
print('project name:', current.project_name)
print('project branch:', current.branch_name)
print('is this a production run?', current.is_production)
self.next(self.end)

step
def end(self):
pass

if __name__ == '__main__':
ProjectFlow()


python flow.py run

The flow works exactly as before when executed outside AWS Step Functions and introduces `project_name`, `branch_name` & `is_production` in the [`current`](https://docs.metaflow.org/metaflow/tagging#accessing-current-ids-in-a-flow) object.

On AWS Step Functions, however, `step-functions create` will create a new workflow `example_project.user.username.ProjectFlow` (where `username` is your user name) with a user-specific [isolated namespace](https://docs.metaflow.org/metaflow/tagging) and a [separate production token](https://docs.metaflow.org/metaflow/tagging#production-tokens).

For deploying experimental (test) versions that can run in parallel with production, you can deploy custom branches with `--branch`

python flow.py --branch foo step-functions create

To deploy a production version, you can deploy with `--production` flag (or pair it up with `--branch` if you want to run multiple variants in production)

python project_flow.py --production step-functions create

Note that the isolated namespaces offered by `project` work best when your code is designed to respect these boundaries. For instance, when writing results to a table, you can use current.branch_name to choose the table to write to or you can disable writes outside production by checking current.is_production.
[Hyphenated-parameters support in AWS Step Functions](539)
Prior to this release, hyphenated parameters in AWS Step Functions weren't supported through CLI.

from metaflow import FlowSpec, Parameter, step

class ParameterFlow(FlowSpec):
foo_bar = Parameter('foo-bar',
help='Learning rate',
default=0.01)

step
def start(self):
print('foo_bar is %f' % self.foo_bar)
self.next(self.end)

step
def end(self):
print('foo_bar is still %f' % self.foo_bar)

if __name__ == '__main__':
ParameterFlow()

Now, users can create their flows as usual on AWS Step Functions (with `step-functions create`) and trigger the deployed flows through CLI with hyphenated parameters -

python flow.py step-functions trigger --foo-bar 42


[State Machine execution history logging for AWS Step Functions](536)
Metaflow now logs [State Machine execution history in AWS CloudWatch Logs](https://docs.aws.amazon.com/step-functions/latest/dg/cw-logs.html) for deployed Metaflow flows. You can enable it by specifying `--log-execution-history` flag while creating the state machine

python flow.py step-functions create --log-execution-history

Note that you would need to set the environment variable (or alternatively in your Metaflow config) `METAFLOW_SFN_EXECUTION_LOG_GROUP_ARN ` to your AWS CloudWatch Logs Log Group ARN to pipe the execution history logs to AWS CloudWatch Logs

2.2.13

The Metaflow 2.2.13 release is a minor patch release.
- [Bug Fixes](2.2.13_bugs)
- [Handle regression with `batch` execution on certain docker images](534)

<a name="v2.2.13_bugs"></a> Bug Fixes
[Handle regression with `batch` execution on certain docker images](534)
Certain [docker images](https://docs.aws.amazon.com/sagemaker/latest/dg/pre-built-containers-frameworks-deep-learning.html) override the entrypoint by executing `eval` on the user-supplied command. The `2.2.10` release impacted these docker images where we modified the entrypoint to support datastore based logging. This release fixes that regression.

2.2.12

The Metaflow 2.2.12 release is a minor patch release.
- [Features](2.2.12_features)
- [Add capability to override AWS Step Functions state machine name while deploying flows to AWS Step Functions](532)
- [Introduce heartbeats for Metaflow flows](333)
- [Bug Fixes](2.2.12_bugs)
- [Handle regression with `Click >=8.0.x`](526)

<a name="v2.2.12_features"></a> Features
[Add capability to override AWS Step Functions state machine name while deploying flows to AWS Step Functions](532)
Prior to this release, the State Machines created by Metaflow while deploying flows to AWS Step Functions had the same name as that of the flow. With this release, Metaflow users can now override the name of the State Machine created by passing in a `--name` argument : `python flow.py step-functions --name foo create` or `python flow.py step-functions --name foo trigger`.

[Introduce heartbeats for Metaflow flows](333)
Metaflow now registers heartbeats at the run level and the task level for all flow executions (with the exception of flows running on AWS Step Functions where only task-level heartbeats are captured). This provides the necessary metadata to ascertain if a run/task has been lost. Subsequent releases of Metaflow will expose this information through the client.

<a name="v2.2.12_bugs"></a> Bug Fixes
[Handle regression with `Click >=8.0.x`](526)
The latest release of Click (8.0.0) broke certain idempotency assumptions in Metaflow which PR 526 addresses.

Page 24 of 28

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.