Bug: Does the `--definitions` list require an other flag after the last item in order to check files?

[echoix]

I'm trying to integrate gersemi in one of my projects. I seem to have found a weird issue in the way the arguments are parsed. From my different combinations, tried, I think that the pattern is that the "--definitions src [src ...] cannot be the last arguement in the list. There needs to be something else after, in order to have it work. I think I observed a weirdness like that yesterday when calling locally with uvx, but at that time I thought it was my errors typing so I went to run with pre-commit (I usually use prek, but validated with by clearing the cache first, then with the plain pre-commit before suspecting this Gersemi tool). When I retry to reproduce some bugs, with an uvx call, I can't seem to make it not work when I add a dot argument (either as the first (before "-i" or "--in-place"), or after all --definitions). With pre-commit/prek, it worked, but placing the arguments in different orders didn't do the same. I found that weird. I shouldn't be adding . for the complete repo in pre-commit, since it handles the files to parse. Thats why I chose to show a reproducer with precommit instead of a command line call.

Calling prek:

prek -a gersemi -vvv

or pre-commit

pre-commit run --all-files

Relevant part of .pre-commit-config.yaml
Working:

  - repo: https://github.com/BlankSpruce/gersemi-pre-commit
    rev: 0.27.7
    hooks:
      - id: gersemi
        args:
          [
            "--in-place",
            "--warn-about-unknown-commands",
            "--definitions",
            "cmake/modules",
            "cmake/find_scripts",
            "--safe",
          ]
        exclude: |
          (?x)^(
              include\/config\.h\.cmake\.in
          )$

Working:

  - repo: https://github.com/BlankSpruce/gersemi-pre-commit
    rev: 0.27.7
    hooks:
      - id: gersemi
        args:
          [
            "--in-place",
            "--definitions",
            "cmake/modules",
            "cmake/find_scripts",
            # "--safe",
            "--warn-about-unknown-commands",
          ]
        exclude: |
          (?x)^(
              include\/config\.h\.cmake\.in
          )$

Not working:

  - repo: https://github.com/BlankSpruce/gersemi-pre-commit
    rev: 0.27.7
    hooks:
      - id: gersemi
        args:
          [
            "--in-place",
            "--warn-about-unknown-commands",
            "--definitions",
            "cmake/modules",
            "cmake/find_scripts",
            # "--safe",
          ]
        exclude: |
          (?x)^(
              include\/config\.h\.cmake\.in
          )$

Not working:

  - repo: https://github.com/BlankSpruce/gersemi-pre-commit
    rev: 0.27.7
    hooks:
      - id: gersemi
        args:
          [
            "--in-place",
            "--safe",
            "--warn-about-unknown-commands",
            "--definitions",
            "cmake/modules",
            "cmake/find_scripts",
          ]
        exclude: |
          (?x)^(
              include\/config\.h\.cmake\.in
          )$

Not working:

  - repo: https://github.com/BlankSpruce/gersemi-pre-commit
    rev: 0.27.7
    hooks:
      - id: gersemi
        args:
          [
            "--in-place",
            "--safe",
            "--warn-about-unknown-commands",
            "--definitions",
            "cmake/modules",
            # "cmake/find_scripts",
          ]
        exclude: |
          (?x)^(
              include\/config\.h\.cmake\.in
          )$

By not working, I mean I add extra spaces before/after parentheses, add one space to indent, capitalize only the F of "if(" of a known recognized file. When working, there are 47 other files to change that get changed in my repo.

Not working cases aren't depending on the use of the --safe flag (with and without can both work and not work).
Not working cases aren't depending on the use of the --warnings-as-errors flag (with and without can both work and not work).
Working case can work with -i or --in-place (didn't re-try for not working cases today).

The working cases all have a flag after the --definitions list.

Idea: Is the argument handling eating up one definition src argument (the last one) as the list of files to work on? That's where my #123 feature request would have helped me give you a better hypothesis.

At first, I thought it was only the order of where the --warn-about-unknown-commands but finally it wasn't the common factor.

[BlankSpruce]

It's not a bug per se as in I can't do anything about it when there are two indefinite list of files, one being definitions after --definitions and one being sources. You've correctly established that you need some "stop" argument for definition list to be considered complete and anything of your examples will work but also you can use -- which is I believe unwritten standard among CLI tools:

gersemi --check --definitions one.cmake two.cmake three.cmake -- source_one.cmake source_two.cmake

Having said that I encourage to define definitions and warn_about_unknown_commands in .gersemirc so that gersemi can pick up these arguments in contexts other than pre-commit hook.

[echoix]

I didn’t think of trying -- as it wasn’t documented. Do you know how it’s called, I can’t seem to find it on Google, nor by reading https://docs.python.org/3/library/argparse.html. I’m curious on what they say about it on how it is included by default

[echoix]

Thanks for your time answering my questions today. (I am at a code sprint for the Grass project, thus the activity)

[BlankSpruce]

https://docs.python.org/3/library/argparse.html#arguments-containing

If you have positional arguments that must begin with - and don’t look like negative numbers, you can insert the pseudo-argument '--' which tells parse_args() that everything after that is a positional argument:

https://docs.python.org/3/howto/argparse.html#specifying-ambiguous-arguments

When there is ambiguity in deciding whether an argument is positional or for an argument, -- can be used to tell parse_args() that everything after that is a positional argument:

It's also mentioned in POSIX guidelines so I was wrong about it being "unwritten standard": https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

Guideline 10:
The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

[echoix]

Oh, so we could just have an update to the README/help contents, and it would totally prevent somebody else from loosing an hour or two…

Thanks for your answer, there was way too maches for "--", and I must have not caught on that it was what I was looking for when looking at the two instances of "-- ".