https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0> &gt; Anything we can help with with t...
# general
f
@hundreds-father-404
Anything we can help with with trying out Pants?
I have a bunch of questions related to differences from bazel. I have an intermediate level of bazel experience: I've written some very simple rules, and defined the build a medium sized multi-language project. is there some "compared to bazel" doc somewhere?
w
hey Kamal! we don’t have a “compared to bazel” doc anywhere, but we’d be happy to answer questions in a thread
having that kind of page would be a good idea (as long as it was very neutral and factual of course!)
f
yeah I'm thinking of a "coming from bazel" doc more than a "vs bazel" doc
w
yea, makes sense.
f
do you prefer a thread per question or should I just ask all questions in this thread? (there's only one or two right now)
w
https://blog.pantsbuild.org/dependency-inference/ does touch on one of our differences with bazel
h
https://www.pantsbuild.org/docs/existing-repositories#migrating-from-other-build-tools-set-custom-build-file-names has a very small section about that, but not quite what you’re talking about. Doesn’t talk about the overall differences between the tools
w
in this thread should be fine: thank you!
f
my initial question is actually about that!
is there a notion of visibility? the dependency inference seems like a great idea, but not every import should actually be allowed.
w
there is not currently, no: we’re not opposed to adding visibility though.
h
In the meantime, you can ignore dependencies you don’t like with 
!
and 
!!
in the 
dependencies
field: https://www.pantsbuild.org/docs/targets#dependencies-and-dependency-inference
w
@hundreds-father-404: yea. but visibility is “producer” side rather than consumer side.
h
ack
f
got it. are there any production users of v2 outside of pants itself?
w
there are yes. we should get a new “powered by” page going so that we can be certain that folks would be comfortable with us mentioning them. but yes
👍 2
the rough ballpark of teams who’ve confirmed that they’re using is probably 10 to 20
f
cool. any non-python users yet?
reminds me of my other bazel comparison question: does pants have an equivalent of persistent workers? if not is it on the roadmap?
w
well, v2 only supports Python currently. we know that there is demand (Java and Go in particular), but as of right now, they’re not using those other languages
f
ah so the only rule authors so far are the core developers?
w
not quite: we’ve had folks from the community develop plugins to add support for docker, publishing, jupyter, and a few other usecases
but no one has tackled a second language at this point… we’re actually running some feedback gathering right now to get an impression of where to focus next (including possibly language support)
@flaky-beard-52072: one related difference from bazel though is that there is no JVM-rule API vs Starlark API… there is only one API for writing language support.
f
that's a big plus. bazel will get there... next year or the year after. android rules are the sore thumb for me there.
h
but no one has tackled a second language at this point
Outside of support for Bash in our example plugin repo, which integrates with Shfmt, Shellcheck, and Shunit2 test runner. https://github.com/pantsbuild/example-plugin
w
ah, right! yep, sorry @hundreds-father-404.
f
overall pants seems to have a lighter concept burden. I should try writing a plugin before actually saying that's true.
w
for sure… i think it’s probably fair to say that bazel’s philosophy is to have more APIs each of which are more limited (ie, rules being applicative, while workspace rules can interact with files/processes).
👍 1
h
We’re happy to help with writing a plugin. Disclosure that the Plugin API isn’t yet fully stable, and we know, for example, that we want to do a revamp of the plugin docs to have more tutorial-style. Also the rule graph errors are terrifying, which we know and plan to improve now that 2.0.0 is out You might want to check out the #plugins channel also
w
one spot where we know that Pants needs a bit more work will be building an alternative to Bazel’s toolchains: our 
@rule
API already supports having differentiated subgraphs based on platform information, and it’s used to invoke as many instances of tools as are necessary (one per relevant python interpreter, for example), but we haven’t used it to support crossbuilds the way toolchains might
👍 1
@flaky-beard-52072: regarding your persistent workers question: no, not yet. there is a distinct possibility that we adopt bazel’s API verbatim. in the past we’ve used the nailgun protocol to support persistent workers (and it’s worked well), but we have not needed them yet for python usecases
f
thanks for the answers. toolchains was one place where I was thinking there's a lighter concept burden. well that and the whole configuration transition machinery.
w
Right. I expect that the result will be much simpler due to what the 
@rule
API naturally enables .. but right now the reason it is simpler is that it is incomplete
👍 1
🙊 2
Open in Slack
PreviousNext
Powered by