@proud-dentist-22844 lets see how much inspiration we can draw from import linter. The stuff that possibly doesn't fit within the “visibility” work can be deferred to a another feature.

❗ I just opened a GitHub Discussion I'd love for the community to chime in on, as it is quite pervasive to our modeling of targets and dependencies. ❗ https://github.com/pantsbuild/pants/discussions/15847 TL;DR one "untyped" dependencies field is certain succinct and ideal, but is starting to show cracks under the weight of the unique use-cases we want to throw at it. So where do we go from here?

Oh! After staring at a diagram of dependencies that I made (manually some time ago, before I found pants), I think I see how I can reverse how I was thinking about things. The current grep-based lint does: This module should not import any of these other modules. Visibility would say: This module is

<private>

which implicitly prevents the other module from importing it.

Does

run

exactly mirror

pex_binary

with default

execution_mode

? Inspecting the tmp process dir this seems true, but wanted to be completely sure. When setting

execution_mode = "venv"

the layout does not change. That's ok, but I want to revise the advice verify applications work using

pants run

before merging PRs being given to our developers to _`pants package` and then execute the resulting

.pex

file if using non-default execution_mode._

Does that answer your question? Or did I misunderstand what you were asking about?

Are you referring to external dependencies, or internal ones?

As for examples of monorepos, https://github.com/pantsbuild/pants itself is a good one

Most pants monorepos I'm aware of are private

But I think @proud-dentist-22844 has a public one?

Yeah, though I'm not done switching to pants. https://github.com/st2sandbox/st2/tree/pants

If you want to play with pants in an open source repo, I'd love the help 😄 just try something with pants and when you run into something that doesn't work, fix it 😉 (with my help).

Hi is there a goal called

resolve

which would show me the resolve(s) for a given target similar to

dependencies

? Or what would be a way to get the resolve for a target? I am trying to debug a case where the test complains that the source file doesn't have the same resolve even though I have set the same resolve for the test and the source.

Hi Shantanu,

./pants peek :tgt

gives you Pants view of things for all targets matching your CLI specs..

It doesn't seem to have the resolve information

Then I’d suspect it uses the default resolve… hmm.. 🤷

Hi, is there a list of significantly complex public projects / repositories that are using Pants ?

If not, I’m specially looking for examples of Python monorepos that are using Pants.

Yeah, it uses the default if

peek

says it's None

I figured out my issue but even where pants is using correct resolve, it doesn't show up in

peek

. I can't find it anywhere in peek's output. I am pretty sure all of them are using the correct resolve.

Hm, what does your output look like? This is an example w/ Pantsbuild/pants repo

[
  {
    "address": "src/python/pants/util/strutil.py",
    "target_type": "python_source",
...
    "interpreter_constraints": null,
    "resolve": null,
    "skip_autoflake": false,
    "skip_black": false,
...
  }
]

BUILD file is

python_sources(name="tests", resolve="vehicle_spec")

Ah, try running on a specific

python_test

target like

./pants src/pyfleet-vehicle-spec/tests/test_panion_ds_vehicle_specs.py

What's going on is that the target generator

python_tests

(with an s) "moves" the field to generated targets and doesn't keep it itself. That was necessary for

parametrize()

+

overrides

to work properly cc @witty-crayon-22786, not sure how we could avoid user confusion here. It is definitely nuanced, and currently undocumented

I am using pants version

2.11.1rc2

Oh one idea: when you run

peek

on a target generator, add a key for

generated_targets

with a list of the addresses of everything generated A conceptual change in 2.11 is we leaned more into "target generators solely exist for boilerplate reduction".

peek

became less useful for target generators. "atom targets" are where all the interesting stuff happens

Hi I am getting Inflection module not found error while executing the entry point to run grprc server . The module is mentioned in the build file and was installed using pip install . Still getting error : Module not found

Related to my last Q ^ about

run

. Version is

2.13.0dev5

. We have a project that contains some

pex_binary

targets with default

execution_mode

. When I do, e.g.,

./pants run ./proj/app/oasmodel:skew

everything works. When another user does it (after pulling the same repo, using the same pants binary,

pants.toml

, etc.), the execution crashes from

ImportError

once a 3rdparty# dependency is encountered. The

skew.pex

are identical (particularly

./.deps

) on first inspection of

./.pands.d/...

. Furthermore,

pants package proj/app/oasmodel:skew && ./dist/proj.app.oasmodel/skew.pex

has the same issue. On the user it does not work for, we tried setting

execution_mode = "venv"

on the target, and

pants package proj/app/oasmodel:skew && ./dist/proj.app.oasmodel/skew.pex

worked. An even more surprising behavior than ^ occurred when we tried

pants run proj/app/oasmodel:skew

-- it worked! But comparing

./.pants.d/venv-mode-run

(venv execution mode) vs.

./pants.d/default-mode-run

(default execution mode), they look basically identical, and

.deps

folders both contain the 3rdparty dependencies. As said, the former fails from importing any module exposed by a 3rdparty dist and the latter succeeds. I would not have expected this behavior given that

run

does its own thing and doesn't care about

exceution_mode

attribute in

pex_binary

(or does it to some extent?). I think my next step is to look where the actual Pex got splayed out on the filesystem (I thought that would be in

.pants.d/

when using

run

, but I guess it's in

$PEX_ROOT/

?) and see how it mapped

skew.pex/.deps

Python distributions into actual importable (or lack thereof) modules. But based on what I've seen so far, it does seem like an issue with Pex execution (not Pex building as the builds look the same) -- are there obvious environment setups that would cause the conversion of dists in

.deps

into importable modules to fail? I am in the process of assembling the complete logs and looking at the process outputs more closely. I'll open an issue for that, but wanted to give a heads up here and see if this prompts any ideas. One thing that I am suspicious of is this user was using VSCode Server (Linux) / VS Code (Windows w/ SSH plugin), and in the output I saw lots of unexpected tmp folders Pex was logging w/

-vscode-

labels in the paths. I wonder if the VSCode is doing something to the environment when using the terminal inside the IDE (but I also tried Putty and got the same behavior, though there could be an

.env

file in the root causing the same behavior).

Has anyone developed restructured text plugins? So far I've heard of the sphinx plugin that was just merged. In particular I see three tools StackStorm uses in the old makefile that pants is destined to replace: readme_renderer: https://pypi.org/project/readme-renderer/ rst-lint: https://pypi.org/project/restructuredtext-lint/ rstcheck: https://pypi.org/project/rstcheck/ What else do you use to check readme syntax and other doc tooling?

Hey folks! I have a monorepo too, how I can use scm version with Pants ?

I have to implement my custom plugin or is there something already done?