record it in pyproject.toml or in poetry.lock?

record it in pyproject.toml because poetry thinks

ansible

does not have any dependencies because it parses setup.py, it doesn't run it. So, it can only pick up on the more basic info included in setup.py. ansible has an "or" dependency, which none of the the python dependency management systems (including poetry) have direct support for. So, it has setup.py logic to say "if cryptography is present, then depend on cryptography, else depend on pycrypto"

Oh hey, check that out, they dropped that funky requirement (not released yet): https://github.com/ansible/ansible/pull/74699

Ah, pants will create a synthetic pyproject.toml using its dep inference stuff etc. So all we need from poetry is to make sure the locking works properly

is the engine able to convert from a

Target

subclass to some other non-target type if there is a rule defined for that conversion? can it do so if the rule is defined to take an applicable FieldSet as input and returns the destination type?

fyi interesting benefit(?) of Poetry lockfile generation is it is more rigid discplined that interpreter constraints are valid. For example:

Oof. Before Poetry 1.2, it does not include

setuptools

and

wheel

in lockfiles. We need those included. But they're currently at 1.2.0a2, and it took 3.5 months for 1.1 to go from a2 to stable release Some options:

Is this error expected?

Exception: Invalid Get. Because the second argument to `Get(BuiltPackage, PythonDistributionFieldSet, PythonDistributionFieldSet(address=Address(testprojects/src/python/hello/native:dist), provides=<class 'pants.backend.python.target_types.PythonProvidesField'>(alias='provides', address=testprojects/src/python/hello/native:dist, value=<pants.backend.python.macros.python_artifact.PythonArtifact object at 0x107324b38>, default=None)))` is annotated with `@union`, the third argument should be a member of that union. Did you intend to register `UnionRule(PythonDistributionFieldSet, PythonDistributionFieldSet)`? If not, you may be using the wrong type (PythonDistributionFieldSet) for the third argument.

PythonDistributionFieldSet is not an @union, but its superclass (PackageFieldSet) is.

@hundreds-father-404 Starting a thread on #12542 here

Any reactions on https://github.com/pantsbuild/pants/issues/12466 ? :)

i’m on release duty for today… i assume that we’re not quite ready to cut 2.7.0rc0, but we should probably try to keep the train relatively on time.

@curved-television-6568: have you been waiting on review for https://github.com/pantsbuild/pants/pull/12467 ?

going to cut the next rcs of 2.5.x and 2.6.x unless someone has something they’ll want to pick in the next few hours

I’ve just found a weirdness with

InterpreterConstraints

with respect to how it orders inputs. Can someone help me understand what the correct behaviour should be here? (test case will appear in thread)

a distracting but maybe interesting tangent from #12548: i wonder whether a lockfile + directory full of loose wheels is sufficient to act as a replacement for the

repository.pex

concept

@enough-analyst-54434: re: #12548: i just realized that there is a facility that we didn’t discuss on friday, that at least superficially looks like it supports composing python artifacts the same way you would compose jars… PEX_PATH

when we run

setuptools

, it doesn’t look like it has any user requirements on its pythonpath: https://github.com/pantsbuild/pants/blob/3be44f011b13a81eb2266a9fc7ae01bd57f7fb2c/src/python/pants/backend/python/goals/setup_py.py#L428-L469 … but we use the default value of

PexRequest.apply_requirement_constraints=True

, meaning that the user constraints are applied to that build. this is probably a more widespread issue, but: the constraints should not be applied there, right?

hey @witty-crayon-22786 fyi the dynamic UI is showing up in CI again, this time "Scheduling: Run Pytest for ..."

I'm hoping to add a new flag to

process_executor

-

--remote-cache-mode={skip,prefer,speculate,require}

but at the moment

remote_cache::CommandRunner

is hard-coded to do speculation... How would folks feel about: 1. Implementing a

SpeculatingCommandRunner

which takes two `CommandRunner`s and just races them, leaving

remote_cache::CommandRunner

to only worry about interacting with the remote cache itself 2. Introducing this flag to

process_executor

? (I actually only care about the

skip

, and

require

flag values, but I figure completing the matrix is worthwhile while doing so)

super bikesheddy, and i apologize in advance, but: we made a decision a while back to use

white

for

INFO

,

red

for

ERROR

, and …

red

for

WARN

. i’ve just fixed application of color to logs under

pantsd

, and the red for warn continues to weird me out a bit.

What's the history for how we ended up with both a

cache_key_gen_version

and a

cache_key_salt

on

Process

? These seem like they could be combined? (And ideally would use the

salt

field in the proto https://github.com/bazelbuild/remote-apis/blob/3e816456ee28f01ab2e0abf72306c1f340c7b229/build/bazel/remote/execution/v2/remote_execution.proto#L[…]9 rather than env vars, though I know

salt

was added after we added these fields 🙂)

Starting the design for supporting multiple user resolves: a major thrust from the proposal in https://docs.google.com/document/d/1sr1O7W9517w8YbdzfE56xvDb72LafK94Fwxm0juIRFc/edit# is that we have "roots" (tests, binaries/dists) be what chooses the resolve. But, complication that

python_library

can also be a resolve root, particularly with

lint

and

typecheck

. Does that sound right?

Got into a peculiar situation running an operation that uses

chroot

.

lambdex-related: Created a PR that would allow users to specify the root module name. As the description states, this allows lambdex to support GCP Cloud Functions (I've never used anything other than GCP and AWS, so don't know what's needed elsewhere). I'm hoping if this is good, and gets in, a nice macro can exist like the AWS Lambda one! https://github.com/pantsbuild/lambdex/pull/21

Trying to look ahead into maybe getting GCP Cloud Function support in pants itself. Would the preference be to re-work the awslambda backend to be more generic, and perhaps becoming a

lambdex

backend? Or would you prefer that a new backend

gcpcloudfunction

be created and duplicate code would exist, but it would be easier to allow for the different types to diverge? I think the second would also prevent a breaking change since the backend name would change?

Any UX thoughts on lockfiles here? For tool lockfiles, you set

[black].lockfile

to either

<default>

(provided by Pants),

<none>

, or a path to your own file. It defaults to

<default>

For supporting multiple user lockfiles, you can set

lockfile=path/to/lock.txt

on targets like

pex_binary

, otherwise it defaults to

[python-setup].lockfile

. You can also set

lockfile="<none>"

to opt out. I can't decide if it should be

lockfile=None

or

lockfile="<default>"

to signal to use the global default...I think the latter for consistency and because it seems like

lockfile=None

would be confusing that people might think it meant "don't use a lockfile"

how do I delete a file from a

Digest

? I am trying to use syntax like the following to do so:

sources_digest = await Get(Digest, DigestSubset(sources_digest, PathGlobs(["!__sources__/go.sum", "**"])))

@hundreds-father-404: what would block enabling tool lockfiles by default (

default='default'

) in 2.7.x? are we concerned that those won’t be resolvable on some platforms?

fyi bikeshed on whether to name it

./pants lock

vs

./pants resolve

vs.

./pants python-lock

vs. something else: https://github.com/pantsbuild/pants/pull/12641. Feedback welcomed!

@witty-crayon-22786 "named interpreter constraints" a la your "named resolves" idea is a great way forward to address my concerns about enabling

interpreter_constraints

by default. Some "blessed" interpreter constraints will be defined via

[python-setup]

, then targets set things like

interpreter_constraints="py2_and_py3"