PRJ Spec is a specification that aims at providing stable environment variables inside a project development environment (i.e. repo) modeled almost 1:1 after the XDG specification.
The following env variables and their target folders are available:
export PRJ_ROOT
export PRJ_ID # if set state is maintained inside their matching XDG_ dirs globally, e.g. for sharing between worktrees
export PRJ_PATH # prepended to `PATH`
export PRJ_CONFIG_HOME
export PRJ_CACHE_HOME
export PRJ_DATA_HOME
export PRJ_RUNTIME_DIR
Useage Ideas:
PRJ_DATA_HOME, for example, is a great location to place a repository’s gc roots.
Concerned with cache control, if you want to teach your favorit build tool some cache isolation tricks, point it to PRJ_CACHE_HOME.
Have executable build outputs placed in PRJ_PATH for convenience and devX.
Keep dev service PIDs and Unix Domain sockets at your fingertips in PRJ_RUNTIME_DIR
Keep your dev secrets in-tree under PRJ_CONFIG_HOME
Future Work:
I’ve been starting a go reference implementation so that tools can leverage language libraries to more easily leverage this specification
I don’t find it particularly odd. I believe it’s inherited from the numtide devshell environment variables, in any case. In the context of looking at project environment variables while working on a project, I think it would be fairly intuitive to understand “PRJ” as “project”. If you know to use these variables, you should already know what they represent: project environment variables. I think the idea is to avoid clobbering other variables with a prefix, since you might be typing this frequently it makes sense to abbreviate it.
On the subject of acronyms (or any “coined” term for that matter).
What they probably really are is a preemptive attempt of tokenization of a concept into a language.
Now that works only beyond a critical mass adopted by speakers, of course.
So before that critical mass they’re always odd and may even feel intrusive.
Form a spec perspective it’s also a bit of a chicken and egg problem, because at the aspirational core of a spec lies adoption, that’s their raison-d’etre.
Are you sure that .envrc is correct? What is “fetchurl”? This is what I see when using it:
❯ direnv allow
direnv: loading ~/code/nix-browser/.envrc
direnv: error Get "%20": unsupported protocol scheme ""
./.envrc:9: https://raw.githubusercontent.com/numtide/prj-spec/9b0ffcd0fddcb261bcd73ad9dad18a096760b4a0/contrib/direnv: No such file or directory
./.envrc:10: sha256-54YaaGly6Q0E8GhFT9fB/h9tN1PDERo2/4R4X0Pdi/c=: No such file or directory
./.envrc:8: : No such file or directory