Add 'lua' action to the editor scripts to call a lua function in the sequence.

[astrochili]

I want to create folders and then run lua code to fill these folders with files. Unfortunately, I haven't found a way to do these two steps consistently in the editor script.

Can't create a folder by the lua code because of the restrictions on using os.execute. But can create folders with a separate shell action with calling mkdir.

But here are no folders yet at runtime of the lua code because the actions haven't run yet. So I have to split my editor script into two commands which the user runs in the sequence by himself.

This looks very strange. Would be great to add lua code execution as a sequence action.

[AGulev]

@astrochili could you pls provide a small example script or even a small project that fails now

[astrochili]

I will make it asap but now you can look at this script.

[AGulev]

It's easy to fix, these functions removed from the editor scripts intentionally

[britzl]

@astrochili could you please explain the usecase and the problem you have?

[astrochili]

The usecase is creating folders and files during importing from TrenchBroom. I want to run lua code and create local folders in one command, but now it's not possible.

One way to do this is to make it possible to add a lua function calling to the actions array, in addition to shell and set. That way I can combine my shell command to create folders and lua command to create files in one command.

Another way is removing restrictions to run these functions. It also can solve the problem, but more "lazy" and less consistent with the current system, since calling lua without returning actions is already a hack in my case — there is no actions here, it's nil.

[astrochili]

Hello,

Just wanted to make sure if my explanation was clear? Or is there some good reason in restricting of os.execute?

To put it very simply, eventually I want to make these two commands as one command. Now it's impossible, because the first command does something in Shell that can't be done in Lua (because of os.execute), and the second does something in Lua that can't be done in Shell (because this is an editor script and my main logic is written in Lua).

[britzl]

Just wanted to make sure if my explanation was clear? Or is there some good reason in restricting of os.execute?

Perfectly clear! We're discussing this request. My opinion is that we should not prevent certain operations in editor scripts. Let's see if we can come to an agreement regarding this :-)

[vlaaad]

The original editor extension design separates reads (editor.get) and writes (actions) for several reasons:

• mental model simplicity: this way, we can use a single editor state snapshot for the command function invocation (active or run). For the user, the results of editor.get are stable and don't change inside the function.
• performance: for active checks, we reuse the same editor state snapshot for every command from every extension.

If we want to add os.execute to run callbacks, there are some problems we need to solve. There might be an expectation that after os.execute, the editor performs a resource sync and updates the evaluation context so subsequent editor.get calls receive updated information. We don't want os.execute, and especially resource sync, in active checks that are used to refresh context menus — this will destroy editor performance.

The way I see the problem is that you have a logic in lua that uses file io, but it has to run after a shell command, which currently cannot be invoked directly. This is a reasonable scenario.

I see 2 solutions to the problem:

• introduce lua action that is invoked with a fresh editor state snapshot. inside the associated function, editor.get calls are consistent, but the results might differ from calls in run. The action returns another array of commands to execute.
• deprecate the action system and instead introduce a side-effecting transaction editor API that applies multiple set actions in a single undoable step. Something like editor.transact({node,key,val}, {node,key,val}, ...). Then, after the editor.transact or os.execute are invoked, we invalidate the editor snapshot, so subsequent calls to editor.get might return different results. We should also prevent calling these functions in active checks.

I prefer the second solution because the first one is semantically the same, but more verbose and alien, even though it's more data-driven, pure, etc; and when it comes to mental models, I would expect to receive different results from editor.get after editor.transact.

Open question: should we save the project before performing os.execute? I'd say yes. @matgis do you have some thoughts on the issue?

[matgis]

Yeah, there are a couple of ways we could deal with this scenario, but it is not as simple as just enabling the os functions.

@britzl maybe add this to the agenda for Thursday so we could discuss it a bit more before committing to a particular course of action here?

[vlaaad]

We decided to make several improvements to the editor scripts:

• #8425
• #8426
• #8427

[astrochili]

Good news, looks like a plan!

[vlaaad]

We now implemented and merged the first improvement (#8425).

[astrochili]

We now implemented and merged the first improvement (#8425).

Great news, just checked it out in 1.6.4 beta - works as expected 👍

But I realised that this is only 1/2 of the unavailable functionality 🙈. Since the script syncs files, before creating a folder I also delete it - to get rid of unnecessary files.

Can I create a task similar to #8425 about editor.delete_directory(recursive: bool) command?

The example of usage: https://github.com/astrochili/defold-trenchfold/blob/editor-script-upgrade/trenchfold/trenchfold.editor_script#L49-L55

[astrochili]

Created a task #8472 and PR #8472. Is it possible to include it in 1.6.4, complementing create_directory?