`go install` support
ayuhito opened this issue · comments
Don't use go install, because gsa uses modded dependencies and replace directive was not allowed by go install.
Installation is a little annoying since I prefer using go install to automatically set up my path. Why do you need to use the replace directive? Can't you just point the go.mod to your modded modules directly instead?
For example:
Line 14 in bc5152c
Could just be replaced with github.com/ZxillyFork/trie v0.0.0-20240428062955-77f35217e179 directly in require instead of using replace. You typically only want to use replace if you're testing a fork to a repo that you want to PR imo.
I think you will also need to update the go.mod module names for the forked packages as well so they can be referenced properly in this project.
The main resistance is on gore, and in fact the difference between it and upstream is really the sum of all the PRs that have not yet been merged. I created these prs, but the author seems to be so busy that he doesn't have time to review my changes. I decided not to keep waiting and created this fork
As a reverse tool, gore will require frequent updates to keep it in sync with the go compiler. If I create too many modifications on the fork branch, resolving future conflicts could be a pain.
And as for trie, I think your suggestion is valid, I'll push a modification to apply it later as the upstream author seems to have stopped updating it.
After all my pr's are merged, go install should be back available.
That makes sense. Personally, I still think it doesn't make a huge difference if you use the gore fork directly now and then switch the import to the main repository when your PR's are merged with that reasoning. It runs identical to replace.
I agree with @ayuhito
@Zxilly You own your fork, you maintain it
if the owner for gore never comes back, which often happens, your fork will become the most interesting one.
I would like to recommend you this extension (Firefox or Chrome)
I suddenly realised that there was another reason why I rejected go install in the first place; the webui mode relies on a built index.html, which is quite a large file and the front-end dependencies are updated frequently, so putting it in the repository would result in the repository size expanding pointlessly fast.
I added a fallback mode to allow static files to be downloaded from GitHub at runtime, and a manually set version variable will ensure they are compatible with each other.
Does it have cache layer? I mean if I'm offline, in a train for example, I couldn't use your tool because it needs to download the file on each run?
For offline usage, you can only use binary in the release. It embed the asset thus no need for network.
Cache can be a good idea. But I'm wondering how to tell the user explicitly: we're going to put some files somewhere on your disk? It doesn't sound like this is intuitive for an analytical tool.