Provide Zed Data Dir as a TaskVariable#59564
Conversation
If this is about the extension case, then wouldn't it be better to include the path to the extension's working directory instead? We don't want extensions having to have knowledge of where exactly on the system we store them. |
|
Having direct access to the extension working directory would be probably better. Less things to consider |
f433217 to
1bb236c
Compare
|
@maxdeviant Changed it. I was using the most generally useful value here on the chance there is a use case for it - but I can't see one myself tbh. To cater to our specific use case the extension work dir directly makes things slightly easier. |
Problem
For extensions providing tasks (like the ones that are exposed as the little play buttons next to e.g. test methods) it is extremely difficult to impossible to do non-trivial things in a platform-agnostic way, because the programming model is polyglot-shell-script-in-a-json-string.
Solution
The primary goal of this PR is to give extension-provided tasks access to the extension working directory (
$ZED_EXTENSION_WORK_DIR/my_extension) so they can dispatch the logic to provided scripts/binaries, which allows for a much more reasonable programming model.It does so by providing the resolved extension work dir (
paths::extensions_dir()/work) as a TaskVariable, so scripts don't have to make guesses and/or duplicate code in above mentioned polyglot-shell-scripts-in-json-string kind of ways in order to dispatch their tasks correctly.Context
I work primarily on the Java extension.
zed-extensions/java#94 is the issue that this would solve specifically for me
zed-extensions/java#274 contains some of our discussions on the subject
#45932 is a much more general approach at this, that would unlock more things to be done with extensions but means changes to the extension api, which comes with dangers and problems
Release Notes:
$ZED_EXTENSION_WORK_DIRTask Variable