Flyte enables production-grade orchestration for machine learning workflows and data processing created to accelerate local workflows to production.

Flyte

Hi! It’s me again. Sorry for piling on the questions. I wonder what’s the python equivalence of <https://docs.flyte.org/projects/flytectl/en/latest/gen/flytectl_get_workflow.html|this>
```Retrieve all the workflows with limit and sorting:

flytectl get -p flytesnacks -d development workflow  --filter.sortBy=created_at --filter.limit=1 --filter.asc```
Thanks!

<https://github.com/flyteorg/flytekit/blob/36fc15168d5923ecfb1c3640f9c2f8acfbe3eb50/flytekit/clients/friendly.py#L251>

<@U04UNGML8NB> do not mind me asking, but you seem to be doing some major surgery on flytekit, can we get a sneak peek at what you are doing :smile:

Hi <@UNZB4NW3S>! Sure, happy to share! My flyte code is in a bazel-powered monorepo, and my big-picture goals are to:
• Register the tasks and workflows programmatically on the fly instead of using `pyflyte register`
• Have a versioning scheme so that each workflow version is associated with a git commit while there is no version conflict when two developers are testing different code in the same git branch
    ◦ I have 3 environments: development, staging, production, and want to be able to:
        ▪︎ for development: register and execute the same version
        ▪︎ for staging: the same as development, plus executing workflows on main with previously registered versions (not necessarily the latest main version)
        ▪︎ for production: execute the latest version registered in production (which is why I’d like to fetch the latest workflow programmatically)
Hope these don’t sound too confusing. I’m open to suggestions on how to do those things the standard way and happy to elaborate more if needed. Thanks :simple_smile:

No this is completely how it’s supposed to be

But you are writing like a helper script for this

Is using `list_workflows_paginated` not recommended?