including disabled scripts/rules in the repo

[fidgetingbits]

is there an 'official' or recommended way of disabling things other than deleting? i often rename files to talon_ or py_ to prevent talon from loading them, but it may be we want to start having some talon files available in the repo, but disabled by default so people can enable them only if they need them. so it may be we want to agree on the best way to disable rules/script files.

I feel like eventually we're going to have so many rule files the new users having to delete all of the one they don't need is going to be harder than them just enabling the ones they do need for their workflow.

I think another useful example for disabled by default scripts would be with debug scripts. right now we kind of rely on the slack channel and people to ask for certain debug scripts and they just keep getting pasted over and over again, but if we included something like debug/ folder with python and talon files that could be used for debugging, and that are just disabled by default, we could just tell people to enable them and then it helps us be sure that they're using debug scripts that actually work as intended. examples would be your debug app command, record.py, etc.

filing discussion as an issue so there is a record that won't disappear due to slack message limits.

[knausj85]

something like *_disabled is probably good enough for the depot, with perhaps a comment on the top of the file too?

Be careful with stuff like record.py, as I know aegis didn't want that shared in github due to private APIs. I asked him about that one, as I thought to include it too.
ventually this stuff will become plugins, long-term.

[fidgetingbits]

fwiw i started using .disabled at some point awhile back. I guess the only change you might want to do (as if you agree with .disabled) is just added to your repo .gitignore? that's what I did in mine anyway. for now I didn't use any sort of comment, but I suppose it makes sense. for now it's mostly just disabling things that are already in your repo that I don't use by default myself, so I don't need the comment. but if things start getting disabled when shipped by default in the repo, that I agree that comment is way more important

[knausj85]

That sounds reasonable.