feat: Support for pyproject.toml
#582
No reviewers
Labels
No labels
Compat/Breaking
Kind
Bad merge
Kind
Bug
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
New language
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: mergiraf/mergiraf#582
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "wetneb/mergiraf:pyproject"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is an attempt at enabling the commutativity of specific fields in a
pyproject.toml
file, following their specs.My impression is that such files are widespread enough to justify having their own language profile, especially because it doesn't cost us much in terms of binary size (as we're reusing a parser that we already include).
Note that I've added the language profile before the TOML one, so that the more specific
pyproject.toml
one is encountered first. Ideally we should not have to worry about this order of definitions and the most specific profile would get selected automatically.This is prompted by a request from Stainless but I'm doing this pro bono (it doesn't actually solve their motivating conflict which appears in a
tool
section of thepyproject.toml
).feat: Support for pyproject.tomlto feat: Support forpyproject.toml
For that, we would probably first try to match by the whole filename, and otherwise fall back to a search by extension. Sounds simple enough, I'll try doing that after this PR
@ -588,6 +588,44 @@ pub static SUPPORTED_LANGUAGES: LazyLock<Vec<LangProfile>> = LazyLock::new(|| {
injections: None,
flattened_nodes: &[],
},
LangProfile {
Could you please add (some version of) the following as a comment here?
We can remove it once we implement filename-first search, but just to be sure for now
@ -591,0 +610,4 @@
r#"(table
(bare_key) @table_key (#any-of? @table_key "build-system" "project")
(pair
(bare_key) @pair_key (#any-of? @pair_key "requires" "license-files" "authors" "maintainers" "keywords" "classifiers" "dependencies" "dynamic")
I think the arrays in the values of the
project.optional-dependencies
are commutative as well?I tried to build a query for that (my very first one, so don't judge too harshly^^):
but when I tried running it on the following snippet:
only the second table (
["four", "five", "six"]
) got highlighted, whereas I thought that the*
in(pair)*
would make its inner pattern match each key-value pair, and thus extract all the tables.One more complication with this is that the snippet above could, AFAICT, be written as follows as well (and that would probably even be the more common approach):
which the query above of course wouldn't match. So I did write a separate query:
and that one actually does match both arrays, but does that mean that we will need two queries just for this pattern alone? That sounds a bit unfortunate..
Somehow the TOML example you give above doesn't seem to parse with the tree-sitter grammar, nor with https://www.toml-lint.com/, and I'm not sure why (beyond the missing comma, perhaps, but that doesn't seem to fix it).
I'm adding the query for the second syntax, removing the
*
because it's not necessary: the query only needs to match one commutative child at a time (each commutative child will correspond to a different match of the overall query).Ah, right, that's because inline tables are apparently required to be on one line, so the following does parse:
I see! In fact removing it from the first query makes it highlight both commutative children as well!
Nice!