Port build graph #10
Closed
Port build graph #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
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.
…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
### Problem Porting contrib/cpp to py3 ### Solution just added an import
### 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
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.