So if those entrypoints have a compatible set of requirements than they can share a single resolve.

we do have some, but there's also the problem where we have something like 150+ 3rd party deps and resolving all of them takes... longer than 12 hours, idk I gave up

maybe identify some services that can share a resolve? that would reduce the number of necessary resolves to less than 15 (but still more than 1)

It's often preferable to have fewer resolves

nd resolving all of them takes... longer than 12 hours, idk I gave up

when imstalling lockfiles from pex, pants only installs the subset of deps you need for a certain task

We could also consider adding a syntax to let you not have to manually list every resolve in order to use

parametrize

.

I think part of the problem is (historically) we had dep-inference off because... reasons, idk

turning that off made things happier

which version of Pants are you on?

2.2

->

2.11.0rc3

we turned it off because someone convinced us we wanted to manually manage our deps, but in hindsight that was a terrible idea

(yes, I know)

fwit, i used to be anti dep inference and now im a total convert. its too hard for humans to maintain, and very unlikely to be as precise. dep inference is file-level (python_source -> python_source). manual deps are usually dir -> dir (python_sources w/ an s)

when we were trying to make build-system decisions, the other candidates included Bazel, which almost won if it wasn't for the fact that Bazel is garbage and has truly awful Python support

I also grow more and more skeptical that monorepos are a net positive

Hi team. I am looking at this documentation https://www.pantsbuild.org/docs/python-third-party-dependencies#custom-repositories I have a custom pypi repo that need authentication. how can I config the user name and password for this custom repo?

is there a way to avoid having to run

generate-lockfiles --resolve=python-default

? I have the default set to a resolve called "all" as if I don't define it, I get something like:

UnrecognizedResolveNamesError: Unrecognized resolve name from the field `resolve` in the target module:target: python-default

Well this is confusing:

⟩ ./pants generate-lockfiles --resolve=all
15:24:21.34 [INFO] Completed: Generate lockfile for all
15:24:21.34 [ERROR] 1 Exception encountered:

  ProcessExecutionFailure: Process 'Generate lockfile for all' failed with exit code 1.
stdout:

stderr:
ERROR: Cannot install pantsbuild-pants==2.11.0rc0, pantsbuild-pants==2.11.0rc1, pantsbuild-pants==2.11.0rc2, pantsbuild-pants== 
The conflict is caused by:
     pantsbuild-pants 2.11.0rc4 depends on pex==2.1.80
     pantsbuild-pants 2.11.0rc3 depends on pex==2.1.79
     pantsbuild-pants 2.11.0rc2 depends on pex==2.1.78
     pantsbuild-pants 2.11.0rc1 depends on pex==2.1.75
     pantsbuild-pants 2.11.0rc0 depends on pex==2.1.72

When building, tagging, and publishing Docker images, is the

publish

goal smart enough to know that if it is being asked to publish an image with

image_tags

that don't exist, that it should

package

first - does that degree of dependency tracking work in the Docker backend?

Hi team. when I inspect the env var in a test running by Pants, I found both PATH (which include conda that just contains python) and _VIRTUAL_ENV_ are presented. I guess Pants/Pex reply on the _VIRTUAL_ENV._ However, if the test spawn a new process which inherit all the env vars, the process will use the conda env from PATH instead of the _VIRTUAL_ENV_. I am wondering how to handle this case?

I am wondering if there is any reason the changed-since flag does not work with a specific target?

@calm-ambulance-65371: do you have a pants plugin in your repository?

is there a way to avoid having to run

generate-lockfiles --resolve=python-default

? I have the default set to a resolve called “all” as if I don’t define it, I get something like:

you don’t need to pass any arguments to `generate-lockfiles`: the default is to generate all of them. so if you have exactly one named resolve in the `resolves` option, that’s what will be built.

but it sounds like you don’t need multiple resolves: in which case you shouldn’t need to rename the resolve or even define a lockfile location, because there are defaults for that (

python-default

): you only need to define one if you need more than one.

relevant to whether you actually need multiple resolves: were you already using a lockfile via these 2.2 instructions? if so, do you know whether you had any inline requirements? if you didn’t have any inline requirements, and you were using a lockfile before, then you don’t need multiple resolves, and can just set

[python].enable_resolves

without defining any additional resolves in

[python].resolves

if I can't download subsystem tools from the internet, is there a way to package them in the repo manually? Or specify an alternate URL

I'm hoping that someone will be able to solve the final part of my Pants puzzle... successfully publishing a Docker image to a Google Artifact Registry Docker registry.,, 🧵

Hello channel general, introducing myself as recommend in the docs 🙂 Starting today to migrate a medium-sized repo to pants. An ex-buck user, already got questions. Hope all are having a good week!

Here goes first: trying to run

pants test --test-use-coverage

fails on M1 with a message such as

1.) The wheel tags for coverage 5.5 are cp38-cp38-macosx_10_14_arm64 which do not match the supported tags of /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3.8:

What I did: • set interpreter_constaraints to >=3.9 • have python3.9 on path, from brew yet the message complains about 3.8, and from /Frameworks. Weird.

----- Encouraged by the awesome responses (thanks again Eric!), here's another question re coverage: I'd like to gradually introduce (and enforce) coverage into my repo. That means I want to set a minimum coverage threshold per directory. How do I do that?