13 posts tagged with "concepts"

An important distinguishing feature of Pants v2 is its ability to automatically infer your code's internal and external dependencies. The information about those inferences is available via the dependencies and peek goals, so that metadata about what modules import from other modules is always readily accessible to you.

If you need to make some functionality available to all engineers in your company, you can author and release a Pants plugin (either internally or via a public PyPI index) independently of the rest of the codebase...

Now you can cross-test or cross-build your code on multiple different platforms concurrently, using Environments. Pants uses its precise knowledge of your build's deps to run exactly the relevant processes inside reusable Docker containers (or evenly remotely on a cluster of workers)…

Alexey reviews the Python packaging landscape. You'll learn more about the options you have, their pros and cons, and how to find the best approach to distribute your Python applications.

Pants balances release velocity and end-user stability via judicious use of deprecation cycles. Experimental backends are a way to get quick feedback on new functionality, before "graduating" it to the formal deprecation policy. Experimental features are still well-supported, and not to be feared!

Unlike earlier build systems, Pants v2 automatically infers your code's internal and external dependencies. And it does this at the file level, so that you get optimal invalidation, caching, and concurrency performance without having to manually create and maintain mountains of BUILD file metadata.

Pantsbuild provides a common interface to run all code quality tools in parallel. This post explores how Pants augments excellent linters such as bandit, flake8, shellcheck, etc. by offering its own linting mechanisms, too, including regex matches, dependency analysis, and metadata checks.

Rather than forcing global or per-project lockfiles, Pants uses a hybrid approach...This allows a repo to operate with the minimum number of lockfiles required to support their conflicting library versions, without necessarily going to the costly extreme of per-project lockfiles.

Working effectively in a monorepo requires appropriate tooling. While Pants can be a really useful system in repos of all sizes and architectures, it has some features that make it particularly appealing in a monorepo setting…

If you're responsible for your organization's codebase architecture, then at some point you have to make some emphatic choices about how to manage this growth in a scalable way. There are two common architectural alternatives to choose from...

Many considerations go into evaluating and adopting a new build system: performance, scalability language and framework support, ease of adoption and use, extensibility, compatibility with existing practices, and more.…