#19774 Treat Pants like a Pants repo New discussion created by thejcannon What I'd like to propose we treat the Pants repo itself like any other Pants repo. What this boils down to is that we don't delegate to a

./pants

bootstrap script here in the repo for running Pants itself, but rather use the latest git tag (e.g.

release_2.18.0a0

) to determine which off-the-shelf Pants to run. This makes the Pants repo not unlike a compiler, where an older version of the code is used to produce the next version. Additionally, the engine compilation is bypassed and

scie-pants

will copy it's own already-compiled engine into the source tree to be used by the Pants-code-as-user-code Pants (at least until Pants can compile Rust binaries 😉) (As a follow-up I'll likely propose we use a Python Build Standlone Python provider for this repo as well.) Why • Faster development in the common case: Not having to recompile the engine when upgrading

main

or switching branches would be a humongous dev lift. • Faster release process: Our post-release steps end up re-compiling the engine which we literally just built. Once those are built and put on a shelf, we should be able to use them immediately. (those two reasons are also abundantly clear when you want to do something extremely simple like

pants run build-support/bin/foo.py

) • Yummy yummy dogfood: We should be able to run Pants on the Pants repo. We should walk a mile in our users shoes (which we already do to some degree). • Gets us over the last hurdle of "one-button-releasing". Right now Pants in-repo requires loading the

VERSION

, which would ideally be replaced with a

vcs_version

target. How What this means in practice is: • We separate our plugins into a different resolve, and those will use the

pants_requirements

macro to find references to

pants

modules • This means any changes required to both the plugin and the core Pants code must be done piecemeal. Change Pants -> release -> update plugins. This is how our out-of-repo plugins make changes, so we should walk a mile in their shoes. • The same is done for engine changes. If you need to change the engine and consume it on the Python side, it must be done across a release boundary • There'll be a way to forcibly compile the binary to engine changes locally We can decide the easiest way to handle these cases. For instance, we could

if VERSION < XYZ: ...

in the source code so the engine/Python changes can still exist in a single PR. pantsbuild/pants