Anyone want to help with a friendly fork of this project?

[johnsonjh]

I see there is a lot of backlog that isn't handled, and I think it would be nice to keep this tool alive.

I've mostly moved on to ripgrep (and will often use ack when speed is not critical) but there are places I prefer to use ag mostly because it works due a balance of the features, speed, and portability offered. I still use ag on AIX, thought rust support in AIX landed in 1.67.0, so I might switch, but regardless, there is a good amount of work that can saved here.

I'd like to make a fork of this project, but I'd also like to clearly state that I don't want to "take it over" or really do much new development on it ... so what I propose is a new project that will operate as a friendly fork, with the following goals - roughly in order of importance - and setting expectations up-front:

1. No new features - The fork would focus only on fixes and improving compatibility and portability, at least to start. Everything it touches should be able to be easily merged back to this upstream. No major refactoring!

2. Automate testing - First focus must be on getting some kind of CI/CD infrastructure going that supports testing with the included tests.

3. Catch-up - Merging any pending PR's that are a) clearly correct, b) solve real problems, and c) pass tests.

4. Bug-fixes - Tracking down and (hopefully fixing) the open issues that have a clearly reproducible tests (i.e. ag just printing "truncated file: Success" when searching ~120M gzip files #1243) which could be git bitsect'ed.

5. Consolidation - Merging in vendor patches (Debian, Red Hat, Gentoo, Ubuntu, maybe others?) or other forks fixes, so these distributions and other projects won't need to do local patching (but only where such patches are clearly appropriate and low-impact.)

6. Bus factor >1 - I would guess doing this as a GitHub organization with a few others is best, so if I get hit by a bus or give up, the project wouldn't die or have to move again.

I know GitLab CI/CD very well, but I wouldn't want to run my own runners for this potential new project, and the free tier is limited. It would quality to get a free Ultimate upgrade, so perhaps it's something to look into, but GitHub actions might make more sense. I'd prefer GitLab but would like to keep this fork on GitHub since that's where this upstream project is.

Anyone have suggestions, maybe want to help? @extrowerk @JFLarvoire @aswild ?

[JFLarvoire]

I agree with all your points, and I'm willing to help.
My personal itch is to merge into the main project the changes I had to do to make ag.exe a good Windows citizen.
A prerequisite for that is to restructure my Systems Tools Library as a components that may be included in Ag as a subproject, instead of being duplicated inline as I do now.
The good news is that I retired from HPE a few months ago, so I have a lot more time now :-)

For the CI/CD testing, I think GitHub can now natively do anything you want using GitHub Actions.
The only CI/CD system I'm familiar with is Jenkins. I've never used GitHub Actions, but I'm not too anxious about learning to use it.
I don't think we have to move to a new host environment like GitLab for that. (Although I don't mind moving if you think it's worth it.)

Jean-François

[aswild]

Hey Jeffery, I'm honored to be apparently prominent enough to be included here :)

I think you've got noble goals and a good plan laid out here; it'd be nice to see ag live on as a usable portable tool. I hacked at ag a bunch because it was a tool I used all the time and it gave me a ton of experience learning autoconf/automake and working on a C project of nontrivial but manageable size.

That said, I've pretty much entirely migrated to ripgrep (except in cygwin) and don't expect to have the time or motivation to continue actively maintaining an ag fork. I may be available to help with or answer questions about particulars, if needed.

If you (or anyone, really) would like to adopt or port anything from my fork, you're certainly welcome to it. Consider all my commits in https://github.com/aswild/the_silver_searcher to be released under the Apache 2.0 license. Attribution, e.g. by preserving git author info when cherry-picking or a line in changelogs, would be appreciated but not required.

Cheers,
Allen

[sten0]

#1257 is now a grave issue for Debian and every derivative Bug#999962 silversearcher-ag: depends on obsolete pcre3 library. I'm thankful to @aswild for solving it in his fork 😄

@johnsonjh, @JFLarvoire, do you think you'll pick up the baton in the next six months, or should we all start writing ripgrep compatibility wrappers, while falling back to ACK on platforms that don't have great Rust support?

[johnsonjh]

@sten0 Hi there!

In short, yes, I do think so, especially in light of this.

I'll see what plan I can come up with in, say, another week or so.

[sten0]

@sten0 Hi there!

Hi @johnsonjh! 😄

In short, yes, I do think so, especially in light of this.

Thank you, it's sincerely appreciated.

I'll see what plan I can come up with in, say, another week or so.

How did it go?

[johnsonjh]

Sorry, been busy..

I see the libpcre3 was removed from Debian sid, so, I guess we better get going soon, huh? I'm wrapping up this project now, thankfully, better late than never, so I can visit this soon.

[hholst80]

@johnsonjh did you get around to forking this and adding a patch? If so I would be happy start pulling releases from your repo instead.

[johnsonjh]

@hholst80 I haven't yet, but it's still on my radar to do. Once we get a new version of DPS8M released, I should have some time to look at it seriously.

Edit: AIX has Rust available now, which helps me, but I still really want to do this because as we all know, ripgrep isn't a 1:1 replacement, and not all systems that can run ag can run rg.