Custom operators about modus HOT 5 CLOSED

Also not sure if we should repeat the arguments in the end call. (i.e. _operator_env_end(id, "key", "value")) For all internal operators this is not needed as these things can be tracked in rust code, but a user writing their own operators may find those useful...

from modus.

@maowtm, thanks for summarizing the discussion. This feels like a macro

$x::with_std(std) => $x::in_env("CFLAGS", f"-std=${std}")

Do we need overlapping regions?

It will be even more interesting if it was possible to define custom cache invalidation conditions. For example, define cache invalidation conditions for git/hg/svn, etc, given some basic intrinsics.

from modus.

@mechtaev

This feels like a macro

Yes, and in fact if we don't consider any internal implementation at all what I had is actually quite a bad syntax. Your macro-style definition is much better IMO. But I just proposed this because it is easy to implement and fits into our internal model. A bit of leaky abstraction I guess.

Do we need overlapping regions?

Probably not.

Custom cache invalidation conditions

Not sure how this would work and what would be the use, as usually people would want to rebuild the thing if source has a new commit...?

from modus.

I had a discussion with @barr, and he suggested to use operators that define conditions of cache invalidation. We were thinking of something like that:

• ::no_cache always invalidate the cache
• ::invalidate_cache_if_before(CMD) invalidate cache if CMD, executed before the layer is applied, returns non-exit code.
• ::invalidate_cache_if_after(CMD) invalidate cache if CMD, executed after the layer is applied, returns non-exit code.
• ::invalidate_cache_if_changed(PATH) invalidate cache if the file/directory changes after the layer is applied.

This is just a rough sketch of the API.

from modus.

Or maybe something like ::invalidate_cache_if_different(CMD_BEFORE, CMD_AFTER)

from modus.