| 1 |
On 05/20/2016 11:44 AM, Michał Górny wrote: |
| 2 |
> |
| 3 |
> I'd make '@' signify group names, like we do for sets. This would have |
| 4 |
> the side limitation that it would make it impossible to filter |
| 5 |
> filenames starting with '@' with the currently supported |
| 6 |
> path-or-filename syntax. |
| 7 |
> |
| 8 |
|
| 9 |
That may be the best we can do, but in that case it's only fair to |
| 10 |
mention the exception in the GLEP. I know you don't want implementation |
| 11 |
details in there, but if *nobody* can come up with an implementation |
| 12 |
that doesn't invalidate some well-defined paths, then we should |
| 13 |
weasel-word the spec so that we don't wind up with zero fully-compliant |
| 14 |
package managers =) |
| 15 |
|
| 16 |
The @set notation isn't as much of a problem since it doesn't collide |
| 17 |
with package atoms... which gives me an idea. If we make "/" illegal in |
| 18 |
group names, then "@dir/*.*" can be interpreted as a path. That's a |
| 19 |
little better. |
| 20 |
|
| 21 |
Or, if we specify that the fnmatch pattern is applied to the absolute |
| 22 |
path, I think you can stick a leading "/*" on any pattern without loss |
| 23 |
of generality. So if you wanted to block all PDF files beginning with an |
| 24 |
"@", then instead of "@*.pdf" you could do "/*@*.pdf". |
Archives