Thoughts @wolfv?

I want to double check with some other tools before making a decision. I really think explicit >> implicit :)

I really think explicit >> implicit :)

I agree on that principle, but it's a pointless distinction here IMO. You cannot have a file ./include and a folder ./include/ of the same name in the same folder, so ./include should mean whichever one of those is present. I find it's a waste of our breakage budget to fight the tide of the most low-level GNU coreutils (e.g. ls) which don't distinguish either.

Since both github actions and .gitignore files also match directories using this syntax, I think we can support it. :)

I think we can support it. :)

No question that you can support the trailing backslash. My point is that you should not gratuitously introduce breaking changes. If you feel strongly about changing behaviour from what conda-build is doing, then warn/deprecate and eventually remove. But every single behavioural difference will make the v1 migration a pain. IMO you should start out as compatible as possible; though of course that doesn't mean though that you cannot change behaviour over time.

Clearly there are cases where behaviour changes are justified, from the POV of semantics, architecture or even just sanity. But enforcing trailing backslashes on folders is hardly worth the migration pain this will cause because suddenly packages don't contain what they were expected to (and you have no way for the recipe manager to know whether a given path without trailing backslash is a file or a folder, so you cannot even catch it during translation).