toolshed/alakazam
2
1
Fork 3
Code Issues 4 Pull Requests 1 Packages Projects Releases Wiki Activity

Config in CWD and resolve ABRA_DIR #4

Merged
moritz merged 1 commits from eCommons/alakazam:config-location into main 2026-05-18 16:43:29 +00:00
Conversation 3 Commits 1 Files Changed 1 +71 -8
dannygroenewegen commented 2026-04-07 12:27:35 +00:00
Contributor
Copy Link

Added support for reading alakazam.yml from CWD and fallback to ~/.config/alakazam.yml. This allows working with a completely separate path for e.g. development.
I also had abra configured with a different abra_dir. When alakazam runs abra, it uses the configured abra dir, but alakazam also had some hardcoded references to ~/.abra. I added get_abra_dir() with the same logic that abra uses internally and replaced all hardcoded references.

  • Support alakazam.yml in CWD
  • Resolve ABRA_DIR using env var or abra.yml instead of hardcoding ~/.abra
  • Add ABRA_DIR to exclude_paths when inside root
Added support for reading alakazam.yml from CWD and fallback to ~/.config/alakazam.yml. This allows working with a completely separate path for e.g. development. I also had abra configured with a different abra_dir. When alakazam runs abra, it uses the configured abra dir, but alakazam also had some hardcoded references to ~/.abra. I added get_abra_dir() with the same logic that abra uses internally and replaced all hardcoded references. - Support alakazam.yml in CWD - Resolve ABRA_DIR using env var or abra.yml instead of hardcoding ~/.abra - Add ABRA_DIR to exclude_paths when inside root
🎉 1
dannygroenewegen added 1 commit 2026-04-07 12:27:37 +00:00
- Support alakazam.yml in CWD f1abf6229f 
- Resolve ABRA_DIR using env var or abra.yml instead of hardcoding ~/.abra
- Add ABRA_DIR to exclude_paths when inside root
decentral1se reviewed 2026-04-08 21:48:38 +00:00
decentral1se left a comment
Owner
Copy Link

Woah, super cool @dannygroenewegen! Great to see this happening. Driving by but LGTM! Not to demand too much but probably it would be pretty easy to create a unit test for get_abra_dir. We have to start writing tests eventually 🙃 I trust @moritz will know better.

Woah, super cool @dannygroenewegen! Great to see this happening. Driving by but LGTM! Not to demand too much but probably it would be pretty easy to create a unit test for `get_abra_dir`. We have to start writing tests eventually 🙃 I trust @moritz will know better.
simon requested review from simon 2026-05-07 11:30:13 +00:00
simon requested review from moritz 2026-05-07 11:30:13 +00:00
moritz requested changes 2026-05-11 13:54:30 +00:00
moritz left a comment
Owner
Copy Link

Thank you for this PR 🚀. It's a nice feature to be able to have completely different project dirs, each separately configured.
I'm just curious for which use cases you use it? I think it's good if you don't want to have any global defaults for all of your projects. Else you would have all of your projects inside one main directory, which contains your global defaults.

On thing that stopped me from directly merging this, is that it only uses the alakazam.yml inside the current path, but if you run alakazam from any sub directory in your project it would fall back to "~/.config/alakazam.yml", which could lead to some confusing behaviour.

Thank you for this PR 🚀. It's a nice feature to be able to have completely different project dirs, each separately configured. I'm just curious for which use cases you use it? I think it's good if you don't want to have any global defaults for all of your projects. Else you would have all of your projects inside one main directory, which contains your global defaults. On thing that stopped me from directly merging this, is that it only uses the `alakazam.yml` inside the current path, but if you run `alakazam` from any sub directory in your project it would fall back to `"~/.config/alakazam.yml"`, which could lead to some confusing behaviour.
alakazam.py Outdated
@ -55,3 +55,3 @@
#}
SETTINGS = {}
SETTINGS_PATH = "~/.config/alakazam.yml"
SETTINGS_PATH = "alakazam.yml" if Path("alakazam.yml").exists() else "~/.config/alakazam.yml"
moritz commented 2026-05-11 13:47:41 +00:00
Owner
Copy Link

To be able to use the project specific alakazam.yml in nested directories, it would be good to use a function similar to get_abra_dir() to find alakazam.yml inside the parent dirs.

To be able to use the project specific `alakazam.yml` in nested directories, it would be good to use a function similar to `get_abra_dir() ` to find `alakazam.yml` inside the parent dirs.
dannygroenewegen marked this conversation as resolved
alakazam.py Outdated
@ -467,8 +467,27 @@ def generate_all_secrets(domain: str) -> None:
print(f"\t {gen_sec['name']}: {gen_sec['value']}")
def get_abra_dir() -> Path:
moritz commented 2026-05-11 13:46:10 +00:00
Owner
Copy Link

A little docstring what this function is doing would be nice.

A little docstring what this function is doing would be nice.
dannygroenewegen marked this conversation as resolved
dannygroenewegen force-pushed config-location from f1abf6229f to 5ee1201b57 2026-05-14 15:57:55 +00:00 Compare
dannygroenewegen force-pushed config-location from 5ee1201b57 to af878c4661 2026-05-15 11:13:16 +00:00 Compare
dannygroenewegen commented 2026-05-15 11:27:24 +00:00
Author
Contributor
Copy Link

Thank you for this PR 🚀. It's a nice feature to be able to have completely different project dirs, each separately configured.
I'm just curious for which use cases you use it? I think it's good if you don't want to have any global defaults for all of your projects. Else you would have all of your projects inside one main directory, which contains your global defaults.

On thing that stopped me from directly merging this, is that it only uses the alakazam.yml inside the current path, but if you run alakazam from any sub directory in your project it would fall back to "~/.config/alakazam.yml", which could lead to some confusing behaviour.

Resolved your comments. I assumed to run alakazam only from root_path, didn't realise it also works from subdirs. Fixed the alakazam.yml lookup for this case.

The main use cases I had in mind for seperating project dirs:

  • I was making changes to recipes for integration and had multiple running with chaos version. I noticed some weird behaviour where different abra calls within a single alakazam call would use different commits of a recipe. I have a hunch for the reason, but didn't fully dig into it. It felt safer to have a completely separate project dir for both alakazam and abra when hacking around.
  • I can imagine the need for managing multiple independent entities: E.g. a single uptime kuma is tied to the root dir, but also sharing multiple project dirs with different sets of admins seems easier than managing that with subdirs.
> Thank you for this PR 🚀. It's a nice feature to be able to have completely different project dirs, each separately configured. > I'm just curious for which use cases you use it? I think it's good if you don't want to have any global defaults for all of your projects. Else you would have all of your projects inside one main directory, which contains your global defaults. > > On thing that stopped me from directly merging this, is that it only uses the `alakazam.yml` inside the current path, but if you run `alakazam` from any sub directory in your project it would fall back to `"~/.config/alakazam.yml"`, which could lead to some confusing behaviour. Resolved your comments. I assumed to run alakazam only from root_path, didn't realise it also works from subdirs. Fixed the alakazam.yml lookup for this case. The main use cases I had in mind for seperating project dirs: - I was making changes to recipes for integration and had multiple running with chaos version. I noticed some weird behaviour where different abra calls within a single alakazam call would use different commits of a recipe. I have a hunch for the reason, but didn't fully dig into it. It felt safer to have a completely separate project dir for both alakazam and abra when hacking around. - I can imagine the need for managing multiple independent entities: E.g. a single uptime kuma is tied to the root dir, but also sharing multiple project dirs with different sets of admins seems easier than managing that with subdirs.
dannygroenewegen requested review from moritz 2026-05-15 11:27:30 +00:00
moritz merged commit 776e86a03a into main 2026-05-18 16:43:29 +00:00
dannygroenewegen deleted branch config-location 2026-05-19 18:57:01 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
simon
moritz
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
3wordchant aadil abra-bot ammaratef45 amras Apfelwurm BornDeleuze carla cas coopcloud cyrnel decentral1se dede fauno iexos jade jjsfunhouse jmakdah2 joe-irving kawaiipunk knoflook kolaente lambdabundesverband linnealovespie moosemower moritz notplants oxaliq p4u1 pharaohgraphy renovate-bot ripclap simon sixsmith stevensting trav val yksflip
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/alakazam#4
No description provided.
Delete Branch "eCommons/alakazam:config-location"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?