Hey, I'm just curious as to a higher level explanations of differences between Bazel and Pants. From a general overview, I see that they both have the same aim and the BUILD files look remarkably similar. • One issue I constantly come across is how to control the toolchain in Bazel. Many developers get around this by just hosting everything in a docker sandbox and allowing the use of host tools or force developers to execute remotely in carefully controlled containers. Others create verbose "toolchain" config files, such as this for C++: https://github.com/codificasolutions/bazel-cross-compile-example/blob/master/toolchain.bzl and try to maintain a custom set of rules. Others use a macro known as

rbe_autconfig

which tries to guess what the toolchain would be in your docker container. I'm unsure if any of these solutions are optimal at the moment so I wanted to know if you did things differently? • Why a deamon? I notice Bazel does the same (or at least similar) and you mention in your documentation it is to keep "the action graph warm" - does that mean you're just doing this to keep the action graph in memory? Do you watch for any files that change and update the action graph in the background? • Does anyone know how the generation of an action graph differs? I assume at a basic level you both try to achieve the same thing. You create a DAG and look what needs rebuilding in the tree when an Action changes. After that, is it just what a Bazel rule and Pants rule actually define as an Action? • How does one create a build rule for Pants? A very brief look at your documentation doesn't elude to any easy way to create a plugin. Though that could be just me not being thorough enough.

Hello! Welcome! For the first questions, I pinged some folks who can answer those questions better than I can. For the last question, that’s solely because we haven’t had the time to finish out the plugin docs yet. We started work on them the past 3 days, so they are still very much a WIP and incomplete. It’s my current project, and I am hoping to finish in the next two weeks. It’ll include an example repository demoing how you could, for example, add a plugin for Bash support. In the meantime, did you attend the Python meetup last night? Plugins are created the same way as demoed last night - using Python 3 coroutines (async/await) with type hints. For example,

@rule
def demo(a: A, b: B) -> C:
  ...

I just joined the Slack group today, so I did not. And if the meetup was evening in the Californian timezone, I most certainly will have been asleep. That's interesting, return types are definitely something missing from Starlark.

Ah, got it. Let me make a copy of the slides from last night - the talk was about how we use Python 3 features like async/await, type hints, and dataclasses to achieve caching, concurrency, and remote execution

Thankyou so much.

not a language such as Go which has both types and coroutines baked into the language?

One of the main reasons is the popularity of Python and accessibility for new developers who haven’t used it before. We wrote the engine in Rust for performance, and the rules API / plugins in Python for accessibility. Another reason is Python’s strong CFFI story, such as a couple Rust projects like the

cpython

crate to talk between Rust and Python. Also, Python 3 now has types and coroutines baked in as well. (Python 2 kind of did, but not in a robust way.)

So for you, it's about expressing what you want done as easily as possible in one language, whilst leaving the harder graph calculation to a compiled language such as Rust.

When you create your Python rules, how do you ensure everyone is using the same Python version, or does it not matter for your usecase?

Good question! See https://pants.readme.io/docs/python-interpreter-compatibility for how to control which Python version is used when Pants makes subprocesses, like when it runs tests For the Python you can use when writing a rule, you can use 3.6, 3.7, or 3.8. Pants requires Python 3.6+ to run itself, so plugins need to be written in Python 3.6. (But your non-plugin code can still be whatever, like Python 2)

with regard to something like Bazel’s toolchains: we’ve begun to sketch options, but don’t have a complete design yet. one of our goals is for multi-platform (multi-host) speculation of requests, so an important aspect of the design is that multiple platforms with different toolchains might be in use in different subgraphs of the action graph

I understand the concept of digesting a file vs just taking the timestamp which is critical to getting a build repeatable. What I don't understand still is why that has to be a daemon.

@big-baker-75091: like Bazel (because we use the same remote execution API), we use SHA256

Is it to stop two processes creating the same hash at the same time?

SHA256 is a few orders of magnitude slower than checking a file timestamp… so you want to keep track of which files have not changed since you last digested them

ah there we go, so it's more about checking to see if a file has changed

yea. that’s important for doing cache lookups and remote execution.

So without a deamon, every time I wanted to run a build, it would have to hash everything all over again. Whereas with a deamon, it hashes everything but when you rebuild, it just checks to see which files have changed and need rehashing in order to recalculate the tree again.

correct.

A C client?

Pants is about 80% python and 20% rust: our client is currently python, but will be ported to rust in the next few weeks

I was more surprised that they have some C in there ^ - ^

yea. they’ve also needed to port various filesystem interaction code to C, because Java exposes limited API there.

I totally agree with you there.

nothing particularly rigorous, unfortunately. it’s quite challenging to compare apples to apples there.