@enough-analyst-54434 if I start with a clean cache

rm -rf .pants.d/

run a test goal with the error in pytest, update pants.ini to pin the old version. Then run pants test goal again with

--cache-test-pytest-ignore

it throws the error.

is there an easy way in a build file to load all of the libraries from another build file? something

src/scala/blah::

By “load” do you mean reference them in a

dependencies=

of a target? No, you have to enumerate every dependency.

src/scala/blah::

is just for specifying targets to act on in command-line invocations. I can see how being able to do this might be useful, but on the other hand it’s likely to cause unnecessarily coarse-grained declared dependencies, which is undesirable. In the long-term we (or at least I…) want to move away from manually-maintained BUILD files towards inferred dependencies (via static analysis, say). There are already various “buildgen” efforts in various stages of usability.

If you need to depend on

src/scala/blah::

in multiple places you can define a target

src/scala/blah:all

that depends on all the other targets, so that you only need to enumerate them once:

yep, thanks

Hi team

What's the current status of Python 3.6 support?

Would you expect pants to squash compiler error messages when

-q

has been passed? I mean, the command fails, but doesn’t have the error?

I thought of an interesting approach to dealing with rglobs that may have nested targets below them https://github.com/pantsbuild/pants/issues/7271

Morning. We've been migrating some of our python code to pants and some folks are complaining about ruined workflows, in particular with regards to Flask app developers being used to "save-refresh" wherein they save a file and it reloads the web server. Has anyone got a similar workflow going with Pants? I guess a watchman that replaces files in the cache is probably what would make it go?

Ah, if this still holds this isn't supported as of now. https://pantsbuild.slack.com/archives/C046T6T9U/p1544572041195600

Hey Omar, we have a similar issue with Django. So we don't use Pants to run a local development webserver - we run it the old-fashioned way (we have a script that sets up a virtualenv with all our 3rdparty requirements - which fortunately are all mutually compatible - for this purpose).

I definitely want to address this within Pants though.

As part of the migration of the Python pipeline to the new engine.

@purple-microphone-26575 At Google, I used to use a command called iblaze. The command watches for changes in files and rebuild automatically the binary file.

Not sure if this has been mentioned before (I didn’t see anything when checking this channel, not sure if another would be more appropriate), but should CI be cancelling builds that haven’t yet run when a new commit gets pushed to a branch?

Noticed this on https://travis-ci.org/pantsbuild/pants/builds/498374233?utm_source=github_status&utm_medium=notification, which continued to run builds after https://github.com/pantsbuild/pants/pull/7283/commits/28d4363f7121f2ee1d37c364dd7c1283ce4e441b was pushed

Related TravisCI docs https://docs.travis-ci.com/user/customizing-the-build/#building-only-the-latest-commit

Seems to be set correctly for PRs already. I will say I have seen this work sporadically. I tend to rebase and force push PR braches alot which I think defeats the Travis CI mechanism.

It consistently cancels builds for me that have not started. If any shard has started already, you have to manually cancel In general, whenever you want something canceled please do ping one of us! CI backlog gets bad during the day so it’s a nice courtesy to everyone

I just tried out the 1.14.0rc3 release and tried running all my python tests and discovered that it couldn’t resolve a bunch of my dependencies (running on a mac) because I don’t have dependencies matching

macosx_10_14_x86_64-cp-36-cp36m

. Running on 1.13.0 I have these dependencies found but they’re reporting all kinds of different macosx levels:

macosx_10_{6,7,9,11,12,13}

(noticeable absent is

10_14

) I’m not entirely sure how I should resolve this, as previously all these dependencies were transparently compiled (and I’m guessing still are since I did a

./pants clean-all

before starting). Any suggestions for how to work with this? I also tried running my tests under 1.14.0rc2 and it all works there so I’m going to take a wild stab in the dark and assume that it’s related to https://github.com/pantsbuild/pants/pull/7156

Why this exception is being thrown?https://github.com/pantsbuild/pants/blob/master/src/python/pants/cache/cache_setup.py#L206-L210

I'm running pants like the following:

./pants --python-repos-indexes=${PRIVATE_PYPI} test ${target} --no-test-pytest-fast \
                --cache-test-pytest-read-from=/tmp/.cache \
                --cache-test-pytest-write-to=/tmp/.cache

@fresh-architect-74417: the cache `read-from/write-to`options are list options

oh, 😄

Thanks

so when you specify them that way, you are adding to the existing list, rather than replacing it

see https://www.pantsbuild.org/options.html#list-options, and try doing something like

./pants options --cache-test-pytest-read-from=/tmp/.cache | grep 'cache.test.pytest.read'

to see the final value

Thanks lot ^_^