ENH: also glob folders under files: without trailing backslash

[h-vetinari]

Currently, rattler-build will -- in contrast to conda-build -- fail to pick up $PREFIX/include/... when doing

build:
  files:
    - include

but will pick it up if there's a trailing backslash, i.e. - include/. In #1051 we discussed:

@h-vetinari: Is it necessary to require the trailing / for folders...? 🤔

@wolfv: Define necessary :D I think if you do ls include you won't see the contents of the folder. So I think in terms of "glob" it's more appropriate, and I also like things to be stricter. But we can totally debate this in another issue.

@h-vetinari:

I think if you do ls include you won't see the contents of the folder.

I see no difference (on my CLI) between ls folder and ls folder/ (both on linux & on win). 🤷

I also like things to be stricter. But we can totally debate this in another issue.

I think we have a breakage-budget for the transition that we shouldn't overstretch. The more subtle behaviour changes accumulate, the harder it's going to be to pull off. [...] for folder-globs I don't see the benefit in terms of clarity gained compared to all the recipe's we'll break -- perhaps silently, because why duplicate in the tests what's already specified under files:, right? -- and then have to remember to look out for and fix.

IMO rattler-build should match conda-build here. It could additionally warn on a missing backslash if it matches a folder, but given that even ls makes no distinction there, this added strictness is IMO a net negative.

[h-vetinari]

Thoughts @wolfv?

[wolfv]

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

[h-vetinari]

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.

[wolfv]

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

[h-vetinari]

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).