I'm in in need of something like

poetry_requirements

but I want to actually use PEP formats and not Poetry. So

pyproject_requirements

. This seems a bit confusing to have both, so I'm wondering whether

poetry_requirements

should be renamed, use PEP-semantics by default and take a flag to enable Poetrys extensions? Or is that slated for deprecation too since Poetry lockfiles are removed now? Any thought? (I'll do the work, just wondering about approach)

poetry_requirements

won't be deprecated, as they are how you specify inputs to Pants

It exists: https://github.com/pantsbuild/pants/blob/54b341bbb50a2e6422de00d17af7075f4f125280/src/python/pants/backend/python/macros/python_requirements.py#[…]2

(first appearance in 2.16.0.dev3)

Ooooh, nice. So many places to check for "exists but not released yet". Awesome!

that’s a good reason to keep a good and stable release cadence too..

I've always wanted a no-branch (lazy branch) release process that releases as you go roughly with feature flags gating not-ready-yet. Sort of like Pex. Always ~stable, always releasing.

that would be amazing. guess the release process would have to be streamlined first in order to make that feasible..?

Yeah, that's the easy part. The harder part is philosophical alignment. Not many people like this sort of thing in my experience.

haha.. as always, the tech part is rarely the biggest issue 😛

There is a perception release branches, etc are more stable and well tested.

like cheese, matures with age 😄

Pex doesn't lazy branch. I've only used that once - with Apache Aurora when it was in-house at Twitter. We had a system called "vert" IIRC, and you did branch, but only in dire circumstances (we did it 2x IIRC) and the branch collapsed quickly once emergency was passed.

at prev work, we had two different release models, based on “gitflow” and “github flow”, where the latter is just feature branches for dev work, which merge in to

main

or similar going forward.