revert(gazelle): revert #1895 as it is causing issues cross-building the plugin

[aignas]

This reverts commit 7fc7962.

#1895 has introduced a way to parse Python files without the need for
Python interpreter by leveraging the tree-sitter bindings for go.
However, those bindings introduced a C dependency and as a result it
was breaking the cross-compilation of the gazelle plugin.

The alternatives to revert are:

• Have 2 code paths, one using interpreter and one using the
  tree-sitter, which would benefit users who don't need
  cross-compilation by speeding up gazelle signifficantly. As
  @dougthor42 showed, the tree-sitter implementation is 3 times
  faster, which is a great performance win.
• Re-implement a parser for the subset of the Python language that we
  care about in pure go.
• Explain users how they can cross-compile the extension, but since
  there is no way to get the OSX sysroot on anything else than OSX os,
  this is not trivial to do.

None of the alternatives look appealing due to increased maintenance or
effort, hence the only real alternative for the time being is to revert.
If the cross compilation of CGO programs becomes better, then we can
look at reverting this revert and using tree-sitter in the future.

Fixes #1913

[dougthor42]

Bummer! I really liked the pure golang helper, haha. Good thing Bazel 7.2.0rc1 is out and I can use git_override for rules_python_gazelle_plugin 🤣

I agree that most options are less than ideal. What does the 2nd option (re-implement) actually consist of? What are the risks?

[linzhp]

We can potentially keep the part of using pypi/stdlib-list to resolve stdlib, which doesn't rely on C.

There are some Python parsers written in pure Go that we can potentially use. Not sure how good they are.

[aignas]

Bummer! I really liked the pure golang helper, haha. Good thing Bazel 7.2.0rc1 is out and I can use git_override for rules_python_gazelle_plugin 🤣

I agree that most options are less than ideal. What does the 2nd option (re-implement) actually consist of? What are the risks?

@dougthor42, your comment suggests that merging this PR would be a mistake, because at least multiple people would use git_override then. :D

The reimplementation of the parser should not be too hard because we cane about a very small subset of the language:

• comments
• if __name__ == "__main__"
• from foo import bar
• import foo

The problem could be that Python is dynamic and it may have these statements within functions, which could means that we do need at least a decent parser to do that.

We can potentially keep the part of using pypi/stdlib-list to resolve stdlib, which doesn't rely on C.

There are some Python parsers written in pure Go that we can potentially use. Not sure how good they are.

@linzhp, Agree, having the pypi/sdlib-list to resolve stdlib is one of the nicest parts here. I haven't found any good parsers in go for Python, so if you could share the options, it would be great. Most of the things I was getting whilst googling were Go parsers in Python.

I'll make this PR a draft, but leave it open in case I hear good reasons for it to be merged. If we just put the cross-building of gazelle as something that our users need to think about themselves, then I am happy with having the CGo implementation of gazelle as the main version.

[linzhp]

I haven't found any good parsers in go for Python

Looks like github.com/go-python/gpython/parser is a decent one