While attempting to "cut out the middleman" and arrive at a locally-compiled binary of this module, I passed the following command to the Go 1.21 executable that was running on Windows 11 with commands passed to a PowerShell 7.4 shell with elevated permissions. I received the following diagnostic information when the compilation it initiated failed:
> go install github.com/onemorebsmith/kaspa-stratum-bridge/cmd/kaspabridge@latest
go: downloading github.com/onemorebsmith/kaspa-stratum-bridge v1.1.71
go: github.com/onemorebsmith/kaspa-stratum-bridge/cmd/kaspabridge@latest: version constraints conflict:
github.com/onemorebsmith/kaspa-stratum-bridge@v1.1.71: parsing go.mod:
module declares its path as: github.com/onemorebsmith/kaspastratum
but was required as: github.com/onemorebsmith/kaspa-stratum-bridge
I attempted to pivot based on the information provided above and tried this incantation instead, however it was even less successful than the first:
> go install github.com/onemorebsmith/kaspastratum@latest
go: github.com/onemorebsmith/kaspastratum@latest: module github.com/onemorebsmith/kaspastratum: git ls-remote -q origin in
${Env:GOPATH}\pkg\mod\cache\vcs\09fc058104eb52193859cbc26d7e4a9d79a159185bdc82fb83e1cd98e7e9c643: exit status 128:
remote: Repository not found.
fatal: repository 'https://github.com/onemorebsmith/kaspastratum/' not found
Prefaced with the obligatory admission that I have essentially zero prior knowledge of Golang and its package ecosystem and an apology if I'm jumping to a laughably absurd conclusion, this would seem to suggest to me, at least prima facie, that the module declaration found here…
…should be modified to match the repository's current URL, doesn't it? It would be good to provide prospective users with a concise and reliable one-line incantation to compile the module, wouldn't you agree? I'm interested to hear your thoughts on how best to accomplish this, and if you can provide a roadmap for the changes required that's accessible to someone with experience in software development in languages other than Golang, I'm more than amenable to prepare a PR to help get the project there.
Salutations,
While attempting to "cut out the middleman" and arrive at a locally-compiled binary of this module, I passed the following command to the Go 1.21 executable that was running on Windows 11 with commands passed to a PowerShell 7.4 shell with elevated permissions. I received the following diagnostic information when the compilation it initiated failed:
I attempted to pivot based on the information provided above and tried this incantation instead, however it was even less successful than the first:
Prefaced with the obligatory admission that I have essentially zero prior knowledge of Golang and its package ecosystem and an apology if I'm jumping to a laughably absurd conclusion, this would seem to suggest to me, at least prima facie, that the module declaration found here…
https://github.com/onemorebsmith/kaspa-stratum-bridge/blob/429f9a4693d381cb9a5552a54aa9712dd20173e4/cmd/kaspabridge/main.go#L11
…should be modified to match the repository's current URL, doesn't it? It would be good to provide prospective users with a concise and reliable one-line incantation to compile the module, wouldn't you agree? I'm interested to hear your thoughts on how best to accomplish this, and if you can provide a roadmap for the changes required that's accessible to someone with experience in software development in languages other than Golang, I'm more than amenable to prepare a PR to help get the project there.
With patience and warmth, Peter