would release.sh require running pants?

the current issue is that pants cannot be bootstrapped.

yeah release.sh calls out to pants

all i normally have to do is

USE_PY39=true build-support/bin/release.sh publish

release pex won't work, but not a huge deal

oh pants does seem to build under release.sh and USE_PY39

% MODE=debug USE_PY39=true build-support/bin/release.sh publish
[=== 00:00 Building native code... ===]
   Compiling pyo3-build-config v0.16.4
   Compiling pyo3-macros-backend v0.16.2
   Compiling pyo3-ffi v0.16.2
   Compiling pyo3 v0.16.2
   Compiling engine v0.0.1 (/Users/yic/workspace/oss_pants/src/rust/engine)
   Compiling pyo3-macros v0.16.2
    Finished dev [unoptimized + debuginfo] target(s) in 12.84s
13:08:30.96 [INFO] Starting: Resolving plugins: hdrhistogram, toolchain.pants.plugin==0.18.0

btw you can still have me do it, but fyi the m1 wheel is just running

USE_PY39=true build-support/bin/release.sh publish-apple-silicon

after

Sounds good. Will let you know if the release script becomes an issue, so I don’t have to carry two laptops out of town hah. Thanks so much!

I should have no problem pushing the PR in, since it’s mostly trivial changes needed this evening.

cool, if you rerun the changelog script it should work (but you'll want to manually delete those 3 entries I flagged)

@fast-nail-55400, @ancient-vegetable-10556: https://github.com/pantsbuild/pants/pull/15347 gets JVM tests running in IntelliJ, with some caveats

Brainstorm invitation: I want to add support for

setuptools_scm

(https://github.com/pypa/setuptools_scm) which is a utility that uses various heuristics to grab a version number out of git (it looks at latest tag+changes since the most recent tag). It is typically invoked in setup.py. It typically writes the version to a gitignored source file (e.g.,

_version.py

) in the source tree. Its configuration, including the destination file, lives in pyproject.toml. I'm trying to figure out how best to implement this in Pants. It's sort-of codegen, but note that there is no original source file, equivalent to a .proto, in this case. In fact, we have to run this codegen every time, and cannot cache it, because git state may have changed from under us.

release prep: https://github.com/pantsbuild/pants/pull/15338

so, afaik, the only issue discovered in

2.12.0a0

was https://github.com/pantsbuild/pants/issues/15315, which was a hiccup due to it being an

a

release. so i think that we can cut

2.12.0rc0

today/by-monday

if anyone else has tried it out and discovered blockers, please ping the thread: otherwise i’ll probably cut this.

I'm trying to ship my improvements to multiple resolves error message today

sounds good.

i’ll wait for ~anything marked

needs-cherrypick

@happy-kitchen-89482: so, one way to more holistically address https://github.com/pantsbuild/pants/issues/15336 might be to merge

--build-patterns

and

--build-ignore

into

--build-globs

, using exactly the same (non-recursive by default) syntax as globs in general. i.e., it would default to

['**/BUILD', **/BUILD.*']

, and you could include inline negation there. that would mean one codepath, and one explanation of globs.

@fast-nail-55400: finally going to get around to https://github.com/pantsbuild/pants/pull/15092 … it sounds like it has fewer unknowns than the rust patch?

I didn't get to finish my last PR in time. gtg. Feel free to go ahead w/ release, I prob wouldn't finish till monday

i might wait till monday then, because i think that https://github.com/pantsbuild/pants/issues/15241 should probably go to 2.12.x too.

and i’m just starting it.

have a good weekend!

ohhh we may want to sneak in tag fix on monday. it's hit several users

yea, fine with me. no real rush.

Given a generic address/target

project/hello/main:cmds

I want to get possible targets it could generate (if any, otherwise I get itself back). I can't seem to figure out how from grokking the code

Design doc for modeling target types for an in-progress Rust backend: https://docs.google.com/document/d/1Q5h0PTusb2WyD3EScgeqUxBPF1IuEXCaa3qO31HEHjQ/edit#heading=h.wj9ig1p17iq0

I'm making a change where I have a bunch of `PackageFieldSet`s and need to do lookup based on

OutputPathField

. Unfortunately it's generic, so I don't have a value to plug into

OutputPathField.value_or_default

. Any objects to adding a mandatory field to

PackageFieldSet

for the

default_file_ending

? I'm guessing there's places this breaks down (like no OutputPath or multiple)?

Getting Pants into some of these "cookie cutter" projects would introduce people to Pants who'd never otherwise considered it. https://twitter.com/glyph/status/1522680851942678528?s=20&t=leXCxUgel5RLygUqtbrAug Is there any obvious reason Pants would not be viable fit for this one specifically? https://github.com/cjolowicz/cookiecutter-hypermodern-python