contrib: add generic shell hook extracted from direnv hook #8
Open
astratagem wants to merge 6 commits intonumtide:mainfrom
Open
contrib: add generic shell hook extracted from direnv hook #8astratagem wants to merge 6 commits intonumtide:mainfrom
astratagem wants to merge 6 commits intonumtide:mainfrom
Conversation
- Rename `find_prj_config` to `find_prj_root_with_config_dir`. This function is not trying to find `$PRJ_CONFIG_HOME` as its name might imply. It looks for a directory named “.config” in order to find `$PRJ_ROOT`, the successful result of which is later used as a fallback method to set the initial value of `$PRJ_ROOT` if `find_prj_root_with_git` yields no result (i.e. this is not a Git repository).
The custom `find_prj_root_with_config_dir()` function is unset towards the end of the script. However, the other custom function `find_prj_root_with_git()` is not unset. I assume this is because the latter was added a couple months after the former, and that the author understandably forgot to unset the newly-added function. I’m not entirely sure about the utility of unsetting either of these functions, but I suppose it does keep the resulting environment cleaner.
They are intended to be sourced in the appropriate context, not executed directly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change aims to leverage the implementation of prj-spec used by the direnv shell hook in order to provide prj-spec environment variables outside of the direnv context.
This means that there does not need to be a dependency on direnv for general usage of prj-spec shell environment additions. Use cases may include: continuous integration pipelines; an oops moment where someone forgot to run
direnv allowand still wants their justfile recipes to work with e.g.$PRJ_ROOT; a hypothetical flake-parts module for prj-spec; and amongst people and organizations who, for whatever reasons, do not use direnv.For the record, I am a big fan of prj-spec and I hope this can be a step towards greater accessibility of its shell integration. I am personally trying to set up a CI pipeline sharing some traits with my development shell, but it feels strange to use direnv in such a context.
Most of the logic in the existing direnv hook by @blaggacao is not actually direnv-specific, so this was a pretty trivial refactor. I am currently using it in my personal configuration project at https://github.com/montchr/dotfield/blob/f4269a6ad7a2762ee3355f112319587a0c05f121/dev/shells/default.nix#L64, and soon in work-related projects (hence the repo owner).
Note that 0c53ebd introduces a breaking change in that existing consumers of the direnv hook will need to reference the new filename
direnv-hook.sh. I made this change to provide clarity as to the file's purpose, especially alongside the newshell-hook.sh. Basing a naming convention off the terse name of the existingdirenvfile could lead to confusion in that a file calledshellindicates very little as to its purpose. I also figured that, considering these files are intended to besourced, they should have a file extension -- in my experience, shell scripts lacking a file extension tend to be executable commands, while these hooks are not used in such a manner.