These are the “intrinsics”, because they are things the engine intrinsically implements without needing @rules

But there is a weird little dance you need to do to actually get them to work

oh wow nice

Let me find out a relevant PR…

https://github.com/pantsbuild/pants/pull/5239/files this is slightly bigger than the version I put together, because it’s actually useful.

Have a look at the following files:

src/python/pants/engine/isolated_process.py adds two types:

ExecuteProcessRequest

and

ExecuteProcessResult

which are similar in structure, but not compatible with, the rust equivalents with the same names

execute_process_noop

is an @rule which needs to exist (I don’t actually know which piece of code needs it to exist), but which is completely ignored because the engine is hard-coded to know what to do for that node in nodes.rs

yeah, those comments on noop rules make sense to me

src/python/pants/engine/scheduler.py passes constructors from the python to the rust when we create the scheduler, so that the rust code can construct the required python versions of the types that that node deals with

There are two changes to src/python/pants/engine/native.py - one of them just adds i32 as a valid type to cross the python/rust boundary, and isn’t relevant, but the constraints and constructor are super important, and are another part of that scheduler.py change

src/rust/engine/src/lib.rs and src/rust/engine/src/types.rs are the rust halves of the “makes sure the rust code can construct the things it needs to pass to the python” part

</description>

i'm not fully able to comprehend the comments at https://github.com/pantsbuild/pants/blob/a9c587416e084327a0eab1ac0640f731a8729357/src/rust/engine/src/nodes.rs#L243 yet, but feel confident i can get there after some more reading. your explanation of intrinsics in nodes.rs was very helpful, although actually everything you just explained was very helpful to get me on the right thought track.

thanks a ton, please feel free to sleep or whatever it is londoners do at this time

I also don’t understand that comment, so if you work it out, please let me know!

I’m also not convinced that that comment is valid any more, now that snapshot creation is incremental

But as I say, I don’t understand it enough to be sure of that

i will let you know! unsure how much more i'll get to tonight but i'm planning to break out a native toolchain subsystem tomorrow which will consume BinaryUtil and it would be #cool to have that converted to v2 -- if i'm lucky i can finish both tomorrow, but i'm only irish in name so not counting on it

Sounds good!

-> bed 🙂 Catch you tomorrow!

see you! thanks a lot for the extensive spontaneous intro to the v2 engine

random thought: a cli overhaul e.g. with curses would dovetail really nicely with making more things into v2 rules -- representing the dynamic state of this thing that schedules things dynamically instead of in sequential tasks is a very interesting question

Yeah, I think that’s what’s motivating @rough-minister-58256 🙂

(I highly recommend you try out Buck, for their UI, though, it’s very nice)

(And implemented in https://github.com/facebook/buck/blob/master/src/com/facebook/buck/event/listener/SuperConsoleEventBusListener.java )

@average-vr-56795 my friend at facebook who does ar stuff in b8 has shown me his use of buck a lot (largely because i ask him about it a lot) -- they have to use cmake for their native stuff (lol) but the console is truthfully really sick imo

also, the buck engineers at bazelconf were very cool and answered a lot of questions i had even though i had a lot of questions

started playing with adding a dep on

reqwests

last night -- would anyone with more intuition have an opinion about whether the network requesting should probably be done in

src

,

fs

(because that's where

Store

is and i'm thinking we'd want to add another store

EntryType

, unsure about that), or in a new subcrate named

net

or something? i was thinking the "right" way may involve making a

net

crate eventually, but was going to stuff it in

fs

for now in case it makes sense to add more `EntryType`s (which makes me think the base

Store

and its entry types shouldn't be coupled to the

fs

subcrate?). probably doesn't really matter for now, just would like to know if i'm on the right track

@aloof-angle-91616: i think that if you haven't decided which crate to put it in yet, you should put it in core rather than fs.