Consider making file regex more permissive

[Matistjati]

After having used the new problemtools, which strictly enforces the regex, it seems to be stricter than what people use in practice. In particular, disallowing files starting with a . or underscore seems to be annoying. Some examples:

• Historically, the Swedish olympiad has renamed generators to _donotuse_generator.sh after the data was generated and final
• .gitignore files have been used by the Swedish Olympiad on a per-problem basis
• I seem to recall domjudge having some dotfile related to time limit, but I might be remembering wrong

These are the examples I am aware of, but surely there are more. I'm not aware of the rationale behind disallowing this. If there is no strong reason, maybe we should allow it?

[Matistjati]

Any thoughts? Pinging @eldering since you have many commits on domjudge and @Tagl since you ran into one such issue.

[Matistjati]

Also ping @niemela, since you probably know why this was added in the first place.

[eldering]

So we (used to) support a file .timelimit in the problem package. But with the new spec that file is obsolete. I'd be against starting files with a dot in general since they're hidden. Would we actually need that for the problem package itself or only for metadata like .gitignore? Because I see that as something that falls outside the spec. I'd be fine with allowing the underscore as starting character.

[niemela]

So we (used to) support a file .timelimit in the problem package.

That was never actually in the spec though. And as the spec is written, they are actually forbidden.

[niemela]

After having used the new problemtools, which strictly enforces the regex, it seems to be stricter than what people use in practice. In particular, disallowing files starting with a . or underscore seems to be annoying. Some examples:

[...]

None of your examples are actually "used" in the package.

The spec currently says All file names for files included in the package must match the regexp <regexp>. The strict way to interpret this would be that it's disallowed for any file within the package to not match the regexp, but it could also be interpreted as any file in the package that does not match the regexp are not "in the package", i.e. can safely be ignored.

All that said though... I do think the first strict reading makes more sense.

[niemela]

These are the examples I am aware of, but surely there are more. I'm not aware of the rationale behind disallowing this. If there is no strong reason, maybe we should allow it?

I agree with @eldering that there are very good reasons to not allow files starting with .. I don't see a good reason to not allow files starting with _ though?

[jsannemo]

I think e.g. .gitignore is a very strong reason to allow . files to exist?

[RagnarGrootKoerkamp]

I think we may have to distinguish here between the contents of a directory during development, and the contents of an archive as uploaded into kattis/domjudge?

I think it makes some sense to be strict and precise about the files uploaded in an archive, so that one can warn for unexpected files.
During local development, however, such warnings are annoying of course.

[Tagl]

I definitely want to be able to have files starting with . Aside from git, many other tools use dotfiles for configurations. I fully support avoiding file names with quotes and spaces and other strange things, but underscores and dots at start is rather normal.

…

On Mon, Aug 25, 2025, 14:17 Ragnar Groot Koerkamp ***@***.***> wrote: *RagnarGrootKoerkamp* left a comment (Kattis/problem-package-format#453) <#453 (comment)> I think we may have to distinguish here between the contents of a directory during development, and the contents of an archive as uploaded into kattis/domjudge? I think it makes some sense to be strict and precise about the files uploaded in an archive, so that one can warn for unexpected files. During local development, however, such warnings are annoying of course. — Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2ZBKVCOS6ZYU3T7J3CN2D3PMLIRAVCNFSM6AAAAACEI4PAPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMRQGQ4DQMJVHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[niemela]

I definitely want to be able to have files starting with . Aside from git, many other tools use dotfiles for configurations.

But isn't the question: "should those files be part of the package"?

[Tagl]

I doubt any of them need to be so I would say no, but they must be allowed to exist in subdirectories during development.

…

On Mon, Aug 25, 2025, 15:06 Fredrik Niemelä ***@***.***> wrote: *niemela* left a comment (Kattis/problem-package-format#453) <#453 (comment)> I definitely want to be able to have files starting with . Aside from git, many other tools use dotfiles for configurations. But isn't the question: "should those files be part of the package"? — Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2ZBKSNSTKXTBEIE3BOQL33PMQ7PAVCNFSM6AAAAACEI4PAPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMRQGY3DGNJWGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[niemela]

In any case. I'm sensing that the consensus is "make the regexp more permissive". I also feel that the consensus is "still don't allow 'quotes, spaces, and strange stuff". It seems that the only real controversy is "dotfiles are bad because they are invisible" versus "dotfiles are useful because they area often used/needed".

After writing it out I'm actually leaning towards the "allow dotfiles" side.

Thoughts? Do you agree with what I claim we agree on? What do you think about the dotfile question?

[ghamerly]

I would like to: allow dotfiles, and allow filenames that start with underscores. In particular, I was recently bitten by verifyproblem failing on __init__.py as well as __pycache__. I think __pycache__ is debatable, but I would argue that __init__.py should be allowed.

[RagnarGrootKoerkamp]

We should then clarify what a pair of files like data/secret/.hidden.{in,ans} is supposed to do.
Same for input_validators/.hidden_input_validator.py and submissions/accepted/.hidden.py.

So yeah, leading underscores are fine, whereas I'd say that files with leading . are allowed but guaranteed to be ignored for everything related to the spec itself?

(It's kinda annoying as a tool writer to make sure all globs/directory iterators consistently ignore dotfiles though... Some probably already ignore dotfiles by default while others don't. It's kinda simpler to be allowed to assume that those kind of things just don't exist....)

[niemela]

So yeah, leading underscores are fine, whereas I'd say that files with leading . are allowed but guaranteed to be ignored for everything related to the spec itself?

As you say, it's kinda annoying to have to "guarantee" to ignore them. Maybe "allowed" to be ignored? That means you can absolutely have a .gitignore, and any other kind of dotfile used by 3rd party tools, but you can't really do .hiddden.in in the data directory.

We should then clarify what a pair of files like data/secret/.hidden.{in,ans} is supposed to do.
Same for input_validators/.hidden_input_validator.py and submissions/accepted/.hidden.py.

What are you suggesting? I really don't like the idea of having data/secret/.hidden.in or input_validators/.hidden_input_validator.py, actually regardless of whether that is supposed to mean that those files are used or are not.