Freezing and deprecating this project

[mvdan]

This project was fun and interesting, but I haven't put a significant amount of work into it for over a year.

The project aimed to solve two main use cases, which I'll cover below. It's also worth noting that a significant part of the initial design came from @rogpeppe.

Querying Go code

One good example is writing custom linting checks. One can always use go/ast and go/types, but having to do that for every little query or check is overkill.

We have https://pkg.go.dev/golang.org/x/tools/go/analysis today, so the barrier to entry has been significantly lowered.

There have also been other projects started in this space since, such as https://semgrep.dev/ (which supports many languages) and https://github.com/quasilyte/go-ruleguard (which actually forked our pattern-matching syntax and code, I think).

Refactoring Go code

This was done by gofmt -r or eg, but they were both too simple to accomplish anything non-trivial.

I firmly believe that refactoring Go code is better served by https://github.com/rsc/rf in the future. That tool is still alpha, but its design is clearly better in multiple ways. It's already been used to refactor Go's own compiler in many ways that gogrep simply does not support, for example.

Current design problems

The API is a list of commands, which is too limiting if one wants to write complex queries. See #32. I tried to do a refactor for this in early 2020 (e933f34), but I didn't particularly like the result either.

The pattern matching is sometimes too stiff; see #4 and #52.

The matching could be more clever, such as comparing evaluated constant values: #43

Moving forward

I don't plan to invest the significant amount of time it would take to make gogrep a competitive tool again, given that it's been outpaced in both use cases as outlined above. Frankly, I'm pretty okay with go/analysis and rf as Go-specific ways to solve both problems in a satisfactory way, and they are both well maintained and better designed.

So I think that gogrep, as a tool in its current form, should be deprecated. There's little reason to recommend its use to others. It would also help reflect the current state of the project.

I still think that there might be value in continuing to develop the internal matching syntax and logic. See #55, for example. I would have absolutely no problem with that, but I don't plan to do that myself.

If someone is willing to step up and take ownership of this project, including the end-user tool, I'm happy to give that person write access - and eventually transfer the repository, once it's shown a bit of progress.

Assuming noone steps up, I think the best course of action is to deprecate the tool and freeze this GitHub repository. Current users of the tool could continue to use it, though the deprecation should discourage them. This would also impact ruleguard, but I think they could simply continue to maintain the pattern matching code in their own repository.

--

Either way the project goes, it's going to be a relief for me - I have other cool stuff that I want to work on, and it's unfair for me to keep this project in its current state if I don't plan to continue it :)

I'll leave this issue open for two weeks before making a decision.

CC @rogpeppe @quasilyte, given your past contributions.

[mvdan]

This would also impact ruleguard, but I think they could simply continue to maintain the pattern matching code in their own repository.

Looks like this has already been happening, so it makes our decision here simpler: quasilyte/go-ruleguard#221

[mvdan]

Assuming noone steps up, I think the best course of action is to deprecate the tool and freeze this GitHub repository.

It's been two weeks, so I'm going ahead with this in 24h. If anyone disagrees or has any more thoughts, please say :)

[quasilyte]

Sorry for the late response.

First of all, gogrep was a tool that blown up my mind. I loved it so much, used the hell out of it.

I'm still using gogrep a lot as a go-to tool for a lightweight syntax-aware code search. It's hard to compete with it in that regard:

• semgrep is far more heavyweight, less convenient to use and it's harder to set up (nothing is easier than a go get if you have a Go toolchain)
• ruleguard isn't that good for CLI usage when all you want is to execute some search query

I haven't looked at rf tool yet, but if it becomes as good in terms of code querying, then it may become a drop-in replacement. But I wouldn't say that it's ready to replace the gogrep right now anyway.

I'm still going to refer to the syntax of the search patterns you implemented in the gogrep as "gogrep patterns".

There are things that could be improved, of course, but I don't see a reason for making it deprecated. It's good enough for its code search use case. If you feel like freezing will make you more comfortable, then you probably should do that; your mental health is more important.

Its search abilities are especially useful when integrated into the text editor (https://marketplace.visualstudio.com/items?itemName=quasilyte.gogrep). The last time I've checked, Goland still didn't have structural code search and replace for Go, but things could have changed since then.

[mvdan]

Thanks for the feedback. Maybe you're right that deprecating might be premature if it still works fine for some people.

To be clear, freezing is not so much about my peace of mind, but as a clear statement that this project isn't maintained. I think keeping it open isn't an honest position, unless there's some plan to bring it back.

I'm still going to refer to the syntax of the search patterns you implemented in the gogrep as "gogrep patterns".

I don't see a problem with that :) The original syntax idea came from @rogpeppe, and I'd be happy for someone else to continue that work if it's useful. It seems like you've been doing that in ruleguard already, as a library.

So maybe I'll freeze it, but instead of outright deprecating the tool, I'll just say it's no longer being developed. In the future I can add a note pointing elsewhere if someone publishes a tool or library others can reuse - as far as I can see, the ruleguard gogrep package is internal.

[mvdan]

I'm going ahead with the freeze, after adding a short note to the README. I'm leaving this issue pinned for reference, and all other open issues/PRs open as-is in case they are useful to anyone.

If someone wants to contact me about this repository or project in the future, you can always do that via email, twitter, matrix, slack, etc.