Just an idea that follows up on a question I had last summer

Question

Just an idea that follows up on a question I had last summer or there abouts regarding how feasible it would be to re use the pants rule engine as a lib Now that I ve come to know things better I think the answer could be a lot easier than you initially though Consider the `RuleRunner` test util it pretty much does this already so I ve got a little toy POC that is a mix of the regular `PantsRunner` and the test `RuleRunner` where I can create a scheduler session with some backends registered and then issue requests against that rule graph Perfect smile This gives me the possibility to write arbitrary applications leveraging the structure and semantics of ` rule` methods for the core logic Awesome rocket As stated it s still on a toy level so haven t actually used this for anything meaningful yet that ll be for the coming month to show how this scales up wink

bitter-ability-32190 · Answer

I m interested in your findings smile

bitter-ability-32190 · Answer

I m also wondering how much size the engine adds to the library And if it can be shared with Pants if the engine is being used by a tool eventually integrated with Pants say a linter

curved-television-6568 · Answer

Posted my toy POC of using Pants as an embedded rule engine in its current state on GitHub This is the main file showcasing what the client application API could look like cc < bitter ability 32190>

curved-television-6568 · Answer

I think the size added could be quite considerable as my toy pex weighs in on 24M

curved-television-6568 · Answer

But I think it would be safe to share with pants as a tool as long as the version matches thinking face

bitter-ability-32190 · Answer

I was actually thinking you could have a flavor that s engineless so you don t end up with 2 pants engines

happy-kitchen-89482 · Answer

Why use the engine as a lib rather than write a plugin

curved-television-6568 · Answer

To not restrict or impose pants way of handling command line options and invocation

curved-television-6568 · Answer

Also consider an existing application it s less work to incrementally implement rules than to toss out the applications cli integration for pants

curved-television-6568 · Answer

gt I was actually thinking you could have a flavor that s engineless so you don t end up with 2 pants engines Sure shipping the lib will just have pants as a dependency so it shouldn t end up with two engines

curved-television-6568 · Answer

But when used in an application that doesn t otherwise use pants it will incur that extra 20 something M s

bitter-ability-32190 · Answer

gt Sure shipping the lib will just have pants as a dependency so it shouldn t end up with two engines edited oh duh

hundreds-father-404 · Answer

This is really cool

hundreds-father-404 · Answer

I wonder if it makes sense to upstream any of this to Pants itself Give you a light weight way to write Pants rules in build scripts without using Pants itself yet maybe Does that make sense < rapid bird 79300> have you seen this thread

witty-crayon-22786 · Answer

neat experiments to simplify the `Scheduler` API upstream are also very welcome i ve found in the past that making it as easy as possible to write tests without shim code is a good sign that the API is easy to use and right now RuleRunner abstracts shims away a bunch of rough edges of `Scheduler` which could probably also be directly smoothed out

hundreds-father-404 · Answer

Great idea And it might be easier to clean things up now that we use PyO3 so FFI is much easier to work with

rapid-bird-79300 · Answer

this is a great idea It can definitely help incremental adoption and make it faster to iterate on simple use cases while leveraging the power of the rules engine The example shared above is a very familiar pattern for a majority of python engineers which can help get more interest in the community and what pants offers

rapid-bird-79300 · Answer

also love the name `underpants` hahah