Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for alternative path for config #153

Open
brizzbuzz opened this issue May 6, 2021 · 7 comments
Open

Allow for alternative path for config #153

brizzbuzz opened this issue May 6, 2021 · 7 comments
Labels
enhancement New feature or request

Comments

@brizzbuzz
Copy link

Description

Hey, seems like the only option currently is to store the config in the root directory, would be nice if we could customize that

Value

Allow repos to avoid clustering dot files in root

@calebcartwright calebcartwright added the enhancement New feature or request label May 7, 2021
@calebcartwright
Copy link
Member

That sounds reasonable, thanks for reaching out with the suggestion!

Due to the nature of the implementation and associated tradeoffs I don't think we'll be able to make this infinitely configurable but should be able to support a few options. Off the top of my head I'd suggest:

  • user home directory
  • configurable via environment variable
  • pre-defined directories (e.g. .rusty-hook/..., .config/..., etc.)

and we'd need to define some sort of priority/probing path across the different options.

Are there any others you'd suggest?

@brizzbuzz
Copy link
Author

hmmm you know... when I opened this it was b/c my friend suggested putting it in the .github directory... but now I'm second guessing that 😅 feels like that should only be for stuff that directly relates to GitHub

I like the idea of .config directory... would be really nice to get all my dot files grouped in a single repo directory

@nirvdrum
Copy link

I've run into a situation where the git repo is a mono repo of multiple Rust projects. Each project would benefit from setting its own pre-commit policy. As of now, rusty-hook doesn't work because .rusty-hook.yml and Cargo.toml don't exist in the same location. I.e., I have something like:

repo
├── projA
│   ├── Cargo.lock
│   ├── Cargo.toml
├── projB
│   ├── Cargo.lock
│   ├── Cargo.toml
└── .rusty-hook.toml

In general, each project is standalone and you can work in one of the project directories exclusively. Even if rusty-hook could work with a shared .rusty-hook.yml, it wouldn't be ideal because each project should define what it's set of checks should be. It would be problematic if projC couldn't push a commit because something in projA fails a new Clippy rule.

@calebcartwright
Copy link
Member

@nirvdrum - thanks for sharing, but what you're describing isn't related to the ask of this issue. I've provided an initial response below but if you'd like to continue on this topic I'd ask that you open a new issue to prevent this one from going off topic.

rusty-hook makes it easier for folks to utilize a client-side workflow with git hooks, but it's not responsible for the specifics of what you want to execute as part of that workflow. There's a very explicit 1:1 relationship between the git repo and the corresponding hooks, neither git nor rusty-hook have any awareness of any logical subsets/groupings of content within a repo.

If you want different behavior based on the contents of the diff, then it's up to you define that process/script which rusty-hook will ensure is invoked for you when the corresponding git hook is triggered.

You'd set your rusty-hook config to something like the below to capture the git args:

pre-push = "sh my_complex_hook.sh %rh!"

Then write your script to presumably inspect those git args to figure out what was in the diff and then react accordingly

@nirvdrum
Copy link

I'm sorry for any confusion. I was laying out my use case to help illustrate the issue I'm encountering. FWIW, I've successfully used rusty-hook for a project with a simpler layout. Thanks for putting out a great tool.

I don't mind adjusting the pre-commit hook to do the correct thing based upon which project's files are updated. But, there seems to be some baked in assumptions that prevent even getting that far. I likely just have the relationships wrong, but rusty-hook init places .rusty-hook.yml in the repo root, but then the pre-commit hook fails to run because there's no Cargo.toml there. If I modify the pre-commit hook to explicitly cd to the correct project directory prior to invoking rusty-hook, it still tries to run from the repo root.

I thought this working directory was being decided upon by the location of .rusty-hook.yml, but maybe that's not the case. I'll try to spend some more time debugging this and file a new issue when I have a better understanding of the underlying relationships.

@calebcartwright
Copy link
Member

@nirvdrum please open a new issue if you'd like to continue the discussion because as noted previously it's not related to this one. It's not entirely clear what you're experiencing based on your previous comments, but I imagine it's something we can help you with (which we're happy to do!). Just want to make sure that happens in the right issue with dedicated focus and that it doesn't steal from the ask/focus of this issue.

FWIW, the rusty-hook config file is a toml only format (no yaml) and rusty-hook itself has no relationship/dependency on the Cargo manifest file. Yes, the working directory for the rusty-hook invocation is the root of the git repository, so if your desired hook scripts involve cargo commands targeting a manifest file in a different directory then you'd either want to provide the --manifest-path opt (e.g. cargo clippy --manifest-path projB/Cargo.toml) or specify and change into your desired directory

@nirvdrum
Copy link

@calebcartwright Thanks. I've just opened #157 to continue the discussion over there. I am sorry for confusing matters in my last comment. Indeed, it is .rusty-hook.toml. I wasn't trying to use YAML for anything -- I just wrote the filename wrong a couple of times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants