I've forked pypa/setuptools into pantsbuild so that Pex 2.x can apply a small patch to support Python 3.10: https://github.com/pantsbuild/setuptools/pull/1

Can I write rules on the dependency inference graph? For example I have two top level packages and I don’t want developers introducing dependencies between them. This is something I would like to enforce in CI

I just got another feature idea, unless you have a better answer to this problem. Not that rarely, a newly added file is not checked into version control. This is tricky, since everything will keep working fine locally, so it will not be discovered (automatically) until you push. I suggest an option to auto-ignore (source) files not under version control. This way, the file would not be picked up by pants, and the issue would surface much sooner.

@fast-nail-55400 fyi: I’m starting first steps on adding support for

export

dependencies for Java dep inference — these are source dependencies that need to be inspected recursively to fulfil a complete type definition for the compiler. I may have some questions about the parsing code at some point, but I’m not certain there’s much to comment on just yet, unless you’ve spent any time thinking about it. (cc @witty-crayon-22786)

@hundreds-father-404: new thread re: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1636568309405000 …

exports

will likely be a second

Dependencies

field for jvm targets, which we would also like to infer (cc @ancient-vegetable-10556)

@ancient-vegetable-10556: how do I resolve a coursier lockfile now with resolves support?

where in the code base are

InteractiveProcess

processes actually spawned?

Got some nailgun logs during the pre commit hook rn. Probably something y’all seen before, but just in case…

I would like to share something really strange on my machine regarding the local cache storage of

pants

. I admit I have a rather large project, and I’m currently using

pants

for running python tests. After really not much runs - it seems that the

pants

cache becomes rather large, and I’m not sure it’s size wise but more quantity wise. I tried to

rm -rf

the directory, that took so much time that I gave up eventually, and used

rsync

which took lots of time (tens of minutes). I decided to run a simple

find

on the directory and time it - is this expected?

[devenv2] ~ ❯❯❯ time find ~/.cache/pants -type f | wc -l
 7333743
noglob find ~/.cache/pants -type f  18.45s user 609.89s system 18% cpu 56:23.34 total
wc -l  1.26s user 1.18s system 0% cpu 56:23.34 total
[devenv2] ~ ❯❯❯

It took a little bit more than 56 minutes to complete I’m using a MacBook Pro - Intel i5 Quad Core with 16GB Ram on an APPLE SSD running macOS Monterey

[GLOBAL].stats

logging reports a bunch of 0s on fully-cached re-run of test. Is this expected?

joshuacannon@CEPHANDRIUS:~/work/techlabs$ ./pants test tools/codeowners/gen_codeowners_test.py:tests
09:49:21.50 [INFO] Completed: Run Pytest - tools/codeowners/gen_codeowners_test.py:tests succeeded.

✓ tools/codeowners/gen_codeowners_test.py:tests succeeded.
09:49:21.50 [INFO] Counters:
  local_cache_read_errors: 0
  local_cache_requests: 0
  local_cache_requests_cached: 0
  local_cache_requests_uncached: 0
  local_cache_total_time_saved_ms: 0
  local_cache_write_errors: 0
  local_execution_requests: 0
  local_process_total_time_run_ms: 0
  remote_cache_read_errors: 0
  remote_cache_requests: 0
  remote_cache_requests_cached: 0
  remote_cache_requests_uncached: 0
  remote_cache_speculation_local_completed_first: 0
  remote_cache_speculation_remote_completed_first: 0
  remote_cache_total_time_saved_ms: 0
  remote_cache_write_attempts: 0
  remote_cache_write_errors: 0
  remote_cache_write_successes: 0
  remote_execution_errors: 0
  remote_execution_requests: 0
  remote_execution_rpc_errors: 0
  remote_execution_rpc_execute: 0
  remote_execution_rpc_retries: 0
  remote_execution_rpc_wait_execution: 0
  remote_execution_success: 0
  remote_execution_timeouts: 0
  remote_process_total_time_run_ms: 0
  remote_store_blob_bytes_downloaded: 0
  remote_store_blob_bytes_uploaded: 0
  remote_store_missing_digest: 0

interesting article on dylint for Rust which allows writing lints without having to fork clippy: https://blog.trailofbits.com/2021/11/09/write-rust-lints-without-forking-clippy/

@happy-kitchen-89482 the example Python repo is slow for me to build on my M1 (30 seconds) because there is no wheel for lxml, so it has to compile. Thoughts on removing

translate

from example-python?

likely not actually feasible, but: defaulting to

--loop

for some goals while in a TTY would be neat.

🧩 I'm seeing this in my test:

E           ValueError: A target of type PexBinariesFromSourcesGeneratorTarget was proposed at address src/python/foo:pex_binaries with explicit sources main3.py, but this target type does not have a `sources` field.

But in

src/python/pants/backend/python/target_types.py

I have:

class PexBinariesFromSourcesGeneratingSourcesField(PythonGeneratingSourcesBase):
    ...

class PexBinariesFromSourcesGeneratorTarget(Target):
    alias = "pex_binaries_from_sources"
    core_fields = (
        ...
        PexBinariesFromSourcesGeneratingSourcesField,
    )

OK, here’s a weirdness:

13:46:50.38 [ERROR] Completed: Compile with javac - core/test/com/googlecode/guice/OSGiContainerTest.java:tests failed (exit code 1).
core/test/com/googlecode/guice/OSGiContainerTest.java:138: error: incompatible types: Properties cannot be converted to Map<String,String>
      Framework framework = frameworkFactory.newFramework(properties);
                                                          ^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

I can’t find a version of

org.osgi.framework.FrameworkFactory

that every took

Properties

as a param, but this seems to live quite happily in the Guice repo. (ping @witty-crayon-22786 @fast-nail-55400)

Are we still waiting on anything for the dev release?

dev release prep PR: https://github.com/pantsbuild/pants/pull/13610

a problem that i expect we’ll see a lot of with multiple resolves (both on the JVM and on Python), and proposal(s): https://docs.google.com/document/d/1BSws879Ii_bM0nu4ZMNyvz6YRtBvaFNj3MXpsvwGdi0/edit# … comments appreciated.

How important is it to the StreamingWorkunitHandler API that the

artifacts

entry uses

Snapshot

rather than

Digest

?

Once every few runs I’m hitting

Resolving requirements.txt

, we realized that it’s because I’m running the code from inside a virtualenv and outside the virtualenv. I think it would be very useful to know that I switched context explicitly. I thought of something like

New env - disgest =

to mark this.

we should probably create the docsite for 2.9

FYI, build wheels (Linux) failed on main (@hundreds-father-404 ?)

FYI Getting CI error post https://github.com/pantsbuild/pants/pull/13526

error: failed to get `pyo3` as a dependency of package `engine v0.0.1 (/__w/pants/pants/src/rust/engine)`

https://github.com/pantsbuild/pants/runs/4212817534?check_suite_focus=true on PR: https://github.com/pantsbuild/pants/pull/13611

@fast-nail-55400, @ancient-vegetable-10556: i’ve bootstrapped a java/scala install in https://github.com/twitter/finagle/compare/develop...toolchainlabs:toolchainlabs/pants-v2-spike

Question we need to figure out before 2.8.0 is stable. What should the address for this be?

python_source(name="app", source="app.py")

Option 1:

project:app

Option 2:

project/app.py:app

🧵

Getting my feet wet with protobufs, but it seems a bit like it doesn’t work to consume them from an in-repo plugin?

I have this snippet in a lockfile: 🧵

blargh. most of these repos have legit java/scala cycles. i might have to lean in on https://github.com/pantsbuild/pants/issues/13520

A draft of the 2.8 blog post. Feedback welcomed! https://docs.google.com/document/d/1eYg0TfemmPF_SCSgQkTF6J4gnvq_2HALMCa4FtZ_mT4/edit#