Page MenuHomePhabricator

Allow a project to have multiple `arclint` files
Open, Needs TriagePublic

Description

In a project, I have a support/arcanist directory which contains a bunch of arcanist extensions for the project (mainly custom linters). Whilst it would make sense to have the support/arcanist tree be a completely distinct repository, it makes distribution (and updates) easier to just leave this subdirectory in the project tree.

The code in the support/arcanist subdirectory is linted to a different standard than the rest of the code in the repository. Specifically, the code in support/arcanist is linted as though it were in rARC itself (making it easier to upstream this code if we wanted to).

For the most part, the support/arcanist subdirectory looks like it is its own repository (it has a toplevel .gitignore, .editorconfig and README files), except for the .arclint file. As a result, the root .arclint file seems a bit messy:

.arclint
{
    "linters": {
        "php": {
            "type": "xhpast",
            "include": "(\\.php$)",
            "exclude": [
                "(^support/arcanist/.*\\.php$)"
            ],
            "severity": {
                "5": "warning",
                "9": "disabled",
                "34": "disabled",
                "37": "disabled"
            },
            "xhpast.php-version": "5.3.29"
        },
        
        "php-strict": {
            "type": "xhpast",
            "include": [
                "(^support/arcanist/.*\\.php$)"
            ],
            "xhpast.php-version": "5.3.29"
        },
        "phutil-library": {
            "type": "phutil-library",
            "include": "(^support/arcanist/.*\\.php$)"
        },
        "phutil-xhpast": {
            "type": "phutil-xhpast",
            "include": "(^support/arcanist/.*\\.php$)"
        }
    }
}

Event Timeline

joshuaspence raised the priority of this task from to Needs Triage.
joshuaspence updated the task description. (Show Details)
joshuaspence added a project: Lint.
joshuaspence added a subscriber: joshuaspence.

I generally don't think we should support this, and installs which have complex .arclint requirements should instead write a script which builds .arclint for them. If you want 5 files with a bunch of variables in them: write bin/rebuild-lint.py or whatever, have it merge the files and do variable replacement, and dump it to .arclint. This script is probably 10 lines long and can do exactly what your environment requires.

Is this a reasonable approach for whatever the underlying use case is?

I also think it would probably be reasonable to do this:

  • If a configuration file like .arclint is not executable, read the file content to load configuration.
  • If a configuration file like .arclint is executable, execute it. Read stdout to load configuration.

.arclint is very powerful already, with include-exclude regexps; What's the use-case for having several?

I also think it would probably be reasonable to do this:

  • If a configuration file like .arclint is not executable, read the file content to load configuration.
  • If a configuration file like .arclint is executable, execute it. Read stdout to load configuration.

I dislike the idea of a configuration file being executable. It just seems like a bad idea.

Let me update the description on this ticket to provide more context, I filed it real quick so that I wouldn't forget about it.

I merged T7037 and T6908 here because they both deal (approximately) with templating .arclint files, and we're definitely not doing the magic approaches in T6908 where some linters get to ignore global excludes.

I'm strongly opposed to building a templating language or inclusion system in the upstream, and think installs which need this should just write a script to generate .arclint. This is easy, straightforward, and you can use whatever language you want (as long as it can emit JSON).

I'm not as completely opposed to the "submodule" case here, especially since it's harder to write a script which does this automatically, but it still seems like a lot of complexity for a marginal use case.