Open alexpovel opened 1 month ago
We don't tie parser versions to the tree-sitter crate (that's what ABI is for, which can be checked independently of the version).
And aren't the bindings autogenerated?
Thanks for your comments!
I'm not sure I understand the versioning scheme. Would appreciate guidance here!
Starting from current HEAD
at 9e3ec9848f28d26845ba300fd73c740459b83e9b , just bumping tree-sitter
as:
diff --git a/Cargo.toml b/Cargo.toml
index d0b9dc6..6341487 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -15,7 +15,7 @@ include = ["bindings/rust/*", "grammar.js", "queries/*", "src/*"]
path = "bindings/rust/lib.rs"
[dependencies]
-tree-sitter = "~0.20.10"
+tree-sitter = ">=0.22.0"
[build-dependencies]
cc = "1.0"
I can regenerate bindings as
cargo install tree-sitter-cli@0.22.6 && ~/.cargo/bin/tree-sitter generate
using 0.22.6
as you did the other day in 9bb99439aa9666a4c407f89759775c5c46557875 . Now git diff bindings/rust
gives
diff --git a/bindings/rust/build.rs b/bindings/rust/build.rs
index 8851fed..718f897 100644
--- a/bindings/rust/build.rs
+++ b/bindings/rust/build.rs
@@ -7,6 +7,9 @@ fn main() {
.flag_if_supported("-Wno-unused-parameter")
.flag_if_supported("-Wno-unused-but-set-variable")
.flag_if_supported("-Wno-trigraphs");
+ #[cfg(target_env = "msvc")]
+ c_config.flag("-utf-8");
+
let parser_path = src_dir.join("parser.c");
c_config.file(&parser_path);
aka no changes in lib.rs
. cargo test
then fails. The changes necessary for Rust to compile I added manually. I will amend the above diff from generate
to the PR as well.
Re: versioning scheme. I found this example where the tree-sitter
dependency was bumped a minor, while the Crate version wasn't.
Is the versioning I chose here wrong? I'm happy to adjust!
The versioning scheme is basically semver, from the point of view of queries (so reflecting minor/major/breaking changes in the grammar only).
And try removing the bindings first; some files are not touched if they already exist.
Thank you. I regenerated after removing first, which gives slightly different results. Didn't squash yet to keep it readable.
Re: semver. The context for my PR is just that I'm trying to get this crate onto crates.io (with tree-sitter
dep as >=0.22.0
). It's not been released on there yet. So an initial release as 0.0.1
(the current one) would probably be fine with semver and is totally fine with my use case. Which initial version do you prefer?
Actually, versioning and publishing should be handled by our workflows; we'd prefer it if there was no "rogue publishing" that can interfere with that.
@ObserverOfTime
Publishing should be handled by our workflows. Versioning should start at 0.1.0 or 1.0.0 (0.0.1 = experimental = unpublishable). (Actually 1.2.0 or 2.0.0 since the parser is currently at 1.1.0.)
P.S. The CLI will help with versioning in the future.
Do we have the secrets configured for this repository? I would add the actions then today
Ideally they should be available org-wide, like the NPM token (as we eventually want to publish ALL THE PARSERS).
Unfortunately, crates does not support team tokens and pypi has yet to approve the org.
Also, for the org-wide npm token to work, the package name must be @tree-sitter-grammars/tree-sitter-hcl
.
@ObserverOfTime Can you set up the token and the publish workflow for this repo then?
Sure, but it would be published on my account.
Can we use our github app? It's a bit annoying that we have to tie packages to personal accounts that may move on, orphaning the package.
The app is for GitHub tokens, not registry tokens.
For reference: https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner . Multiple individuals (all fully entitled) can be made owners, alleviating the issue of orphaning. Teams can then be entitled to publish crate updates etc.
Hey folks, is there a way I can help move this forward?
Upstream base
tree-sitter
has seen some updates this now incorporates.It also bumps this crate's version. The scheme chosen is for the Rust crate's version to be in lockstep with the
tree-sitter
dependency. Looking at the major tree-sitter libraries, this seems to be the general style chosen. For example:The commit also adjust the Rust code to be compatible (the
&'static
change was just a lint, not a compile error).cargo build
andcargo test
now pass.