pants

doesn't play well with `pyenv`: say both python

3.6

and

3.7

are installed via

pyenv

and

3.6

is configured to be used;

command -v python3.7

would not die and

pants

would be tricked to use

python 3.7

. Then

pants

would fail with:

circleci@ip-10-100-196-106:~/project$ python3.7
pyenv: python3.7: command not found

The `python3.7' command exists in these Python versions:
  3.7.0

saw this article floating around, might be of interest to some people here: https://beepb00p.xyz/mypy-error-handling.html

Hi all

I am about to cut a release, waiting on a hotfix to pass CI

if you can hold off merging commits until I land that, it would be appreciated

getting close to done, so not too long to wait

thanks!

My commit landed and I think you are unblocked from landing commits. The CI won't go green again until after the release though, FWIW

python question: is there a way to define a decorator that can either be called with an argument or without one?

another python question: is there a concise way to ensure that a dictionary only contains a certain set of keys?

I mean, other than calling

.keys()

on it and checking that against a set of approved keys

like, is there some nice syntactic trick for this?

that is part of what our

match

function for enums does — i’d totally recommend either using an enum in your case, or, if not applicable, adding the logic to do that check to

pants.util.collections

kind of like the

assert_single_element

method for iterables that we already have there

I opened an issue to discuss cmd-line specs that don't represent addresses: https://github.com/pantsbuild/pants/issues/8593

Would love your thoughts

LOVE IT!

On this subject, where do the specs get provided? I see the

RootRule(Specs)

declaration, but I don't see where an actual concrete instance of the

Specs

class is injected as a param.

Hello everyone

I have an issue sharding tests with junit

I try to use the flag:

Untitled

But it just seems to be ignored, is there anything else to setup to make it work?

https://github.com/pantsbuild/pants/pull/8568 adds options to specify retry behavior and connection pool size when fetching from the v1 http artifact cache! i tried to avoid adding any special logic and focused on just mapping pants option values to constructor args for

requests

and

urllib3

classes. i'd really like to merge this sooner rather than later so i will probably merge before Sunday if nobody has time to review. this is a first attempt at solving this problem, it's scoped to a single subsystem so we can deprecate this approach en masse if it turns out to be wrong at first -- which is why i'm leaning towards trying to merge it earlier, so i can get feedback from users on whether it's working. this would be a massive win for many pants users at twitter who try to develop on a train or plane, and i suspect it will be similarly useful for other organizations using pants.

and just for the record, since i thought this message was useful: https://pantsbuild.slack.com/archives/C046T6T9U/p1573266727243100?thread_ts=1573266343.241600&cid=C046T6T9U

I'm responding to the feedback on https://github.com/pantsbuild/pants/pull/8586 about user-visible error messages

and it seems like right now we pretty much expect to implement user-facing errors by throwing an exception, letting the exception stacktrace show up in the console, and then letting the end user read the error message out of the exception traceback

which seems awkward

I'm not sure if I'm just not doing something to make this more readable, or if this is an actual missing UX feature