This only served to set interpreter constraints we already express in
pants.ini, and at a higher precedence, making attempted overrides via
environment variable silently fail.

Part of pantsbuild#6062.

Part of pantsbuild#6062.

Part of pantsbuild#6062.

Fixing issue from the port of buildgen of missing dependency in BUILD file from pantsbuild#6110.

While technically everything runs correctly without this declaration, that is an implementation detail that should not be relied upon.

### Problem

update for py3 compatiibility

### Solution

Just need future and builtins import.

Part of pantsbuild#6062

just needs builtins imports

### Problem

Port mypy to py3
just imports at issue

### Solution
Futurize script is it.

Followup for pantsbuild#6062. Almost all automated changes, the exception of the change from using `map()` to a for loop.

Part of pantsbuild#6062.

Closes pantsbuild#6001

)

Right now, this is in an and_then block, so doesn't get called if process execution fails.

…we don't use the first cached one (pantsbuild#6022)

### Problem

I made pantsbuild#5479 because the dist resolved for a `python_dist()` would not change after changing any of the source files, and this persisted even after a `clean-all`. This issue is more thoroughly explained in pantsbuild#5449 (which I literally didn't see before making this PR, but describes almost exactly what this PR does, it seems -- great minds think alike?). We were building the `python_dist()` targets each time they were invalidated, but caching the package locally in `~/.cache/pants/` after we built it the first time and using that instead, because the version string was the same for both the first and subsequent builds of the `python_dist()` target.

### Solution

- Move argv generation for setup.py invocations into `BuildLocalPythonDistributions`.
- Append the `python_dist()` target's fingerprint to the version string using `--tag-build`. This conforms to the "local" version specifier format as per [PEP 440](https://www.python.org/dev/peps/pep-0440/#local-version-identifiers). This tagged version is then used in the synthetic `PythonRequirement` stitched into the build graph for the local dist.
- Add an integration test `test_invalidation()` using `mock_buildroot()` (which fails on master, but not in this PR) where we run a binary depending on a `python_dist()`, rewrite the contents of a source file to change the output, then run pants again to verify that the new dist is resolved.

*Separately:*

- Made `PythonDistribution` subclass `PythonTarget` to avoid duplicated logic. It's not clear what the original reason for not subclassing it was at first, but it seems to be not be in effect anymore.
- Changed the `dir` field name for the `Manager` namedtuple in `mock_buildroot()` to be `new_buildroot` so it doesn't get highlighted as a builtin in certain text editors.

### Result

When we resolve local dists in any python requirements task, we get the dist corresponding to the target we just built. Resolves pantsbuild#5449.

took futurize

### Problem

Port scrooge to py3 -- took futurize suggestions

### Solution

ported

### Problem

Porting to py3

### Solution

futurize

Part of pantsbuild#6062

Part of pantsbuild#6062.

### Problem

Porting contrib/cpp to py3

### Solution

just added an import

Part of pantsbuild#6062.

Part of pantsbuild#6062.

Part of pantsbuild#6062.

### Problem

Upgrading go to be compat w/py3

### Solution

Very few, script handled 100% but I did revert a couple of excess lists.

This picks up python3 std lib module knowledge.

In addition, remove the un-needed isort 3rdparty dep and the
contrib/python/src/python/pants/contrib/python/isort binary. The isort
pex is now directly built via script in pantsbuild/binaries.

Fixes pantsbuild#6149

Part of pantsbuild#6062.

Fixes pantsbuild#5995

We were running `--write-mode=diff` which used to exit 4 if your code as
incorrectly formatted, and now doesn't. It now only exits non-0 if
your code doesn't parse. `--write-mode=check` *does* exit non-zero if
your code isn't correctly formatted, but provides no way of
distinguishing "Your code is incorrectly formatted" from "your code
doesn't parse". So that's nice of it.

)

### Problem

The new targets introduced in pantsbuild#5815 have no means of declaring, fetching, and using third party native dependencies.

### Solution

Integrate the Conan package manager to fetch packages from a remote package store via a new task, copy the package data to the results directory of `third_party_native_library` targets in play, and create a product that the compile and link tasks can consume. Plumb the directory paths provided by the product through to the command lines of the compile and link steps.

### Result

Users can now depend on third party native libraries in their `ctypes_compatible_cpp_library` targets from either conan-center or a remote URI that they specify via an option.

## Some notes
- The conan home directory is currently under .pants.d, instead of ~ or ~/.cache/pants. I did this for the short term to make debugging cache problems and other issues as simple as a ./pants clean-all. I don't think the perf loss will be too bad (1-2 seconds).
- Some string manipulation could be better done as regex, and I have TODOs for that
- I am going to follow up with upstream Conan about getting a flag for cleaner client output so the parse method does not need to be so ugly.

…build#6181)

### Problem

`pkill -f "pantsd \[" pantsd-runner && ./pants --enable-pantsd help` fails on master when run within a tty because we incorrectly try to pass an `int` directly to a `bytes`. This was introduced during pantsbuild#6159.

### Solution

- Wrap the `bytes()` argument in a list in `NailgunProtocol.isatty_to_env()`.
- Add unit testing which mocks out the tty querying to ensure the environment we return is valid.

### Result

No more crashing when trying to create a pantsd in a tty.

#### Thoughts

This may be another argument for something like pantsbuild#6157. There may also be room for an integration test which opens up a "real" pty to catch issues like these in the future, but it's not clear to me how to do that right now.

* add 1.9.x.rst copied from previous release notes

* add dates and SHAs

* bump VERSION file

* learn how to use release-changelog-helper.sh

* revert VERSION file changes

* copy 1.9.0rc0 notes over into master.rst

* Revert "revert VERSION file changes"

This reverts commit d031577.

* run ./build-support/bin/contributors.sh

* convert ---- subheading to ~~~~~~

* bump release candidate date

* update changelog after rebase

* add bugfix commit

Also, default is 3M not 10M, as grpc has a ~4M limit per-message

Previously we relied on a pre-deployed `isort.pex` binary; now we
create an `isort.pex` locally as-needed.

Deduplicate test config.

…graph