It appears the ffi module in the Unix port is a "Foreign Function Interface" library, correct?

And I'm assuming you mean this micropython-schedule library?

Yes and yes. In my understanding, micropython-schedule is internally using functools for building function partials which depends on FFI functionality.

Well, the functools in micropython/micropython-lib doesn't appear to need FFI.

You're right, my bad. Below is the error I'm getting. It seems that the time module is choking. Have you seen this before?

import schedule
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/lib/schedule/__init__.py", line 39, in <module>
  File "/lib/time.py", line 4, in <module>
ImportError: no module named 'ffi'

The time module in micropython/micropython-lib will only work on the Unix port, because it's using FFI to access libc for the time functions.

There's a built-in µPy time module in the ESP32 firmware. It appears that that time module will probably work with the micropython-schedule; seems to have all the necessary functions. Should just be a matter of deleting time.py from your ESP32 filesystem.

@dpgeorge Why do we have a "pure" Python time library that will only work on Unix (i.e. not at all pure)? Why not a built-in C time library?

Why do we have a "pure" Python time library that will only work on Unix

Good question! The history of the micropython-lib repo is that it was intended to be individual add-on modules for the unix port of uPy. But over time some of the modules there have been written to target all ports of uPy (eg uasyncio, umqtt), and some other modules might work on any port because they are "pure".

ffi is not supported on esp32. To get micropython-schedule working on the esp32 would require modifying it to not rely on ffi.