Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit :
Le 2019-03-13 20:33, thepudds1460@gmail.com a écrit :
However, even in advance of that, I have seen different people put together one-off shell scripts or similar that are capable of putting a properly formed entry into the module cache such that it can be used by GOPROXY=file://your/path. For example: https://github.com/komuw/goproxy/blob/master/goproxy.sh#L71
And I have my own (unpublished incomplete and unfinished) code to try doing the same thing. Not elegant code I'm especially proud of, just quick and dirty “get it to work before august” code.
Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/
You can add it to your collection of code that tries to do things with Go modules.
That shows up pretty clearly that what should have been a very light and thin wrapping of go upstream module tools, with some custom code to translate go version syntax to rpm version syntax, is anything but light and thin, and requires digging deeply in internal go code, and extrapolating from go help messages.
(for example the very light testing I did this afternoon shows that go version strings do not pass the roundtrip test, so either I can not wrap my head around go module pseudoversion documentation, or the go tool is doing something else than what is documented, or a mix of both).
A thick compatibility layer (not calling directly high-level exported APIs or go commands) basically means there is a high risk of future divergence and incompatibility.
And the published code still needs to grow a command to generate list files, and it's missing a call to tidy the go.mod content after the module zip content changed, and probably other things I have not identified yet.
And, I have no clue how to feed the result to the go build and go test commands in addition to a GOPROXY system directory and the content of the user Go cache, since the whole point is to prepare clean candidate module files, and they can not be mixed in the same directories as other modules while this processed is not finished. But my cunning plan right now is to focus on creating and inspecting modules, and just let Jakub deal with the compiler-side problems in Fedora. I don't have enough braincells left to do both at once. And I still need to write the matching adaptation layer rpm-side, which Jakub won't do.
Regards,
Le 2019-03-26 20:42, Nicolas Mailhot a écrit :
Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit :
Le 2019-03-13 20:33, thepudds1460@gmail.com a écrit :
However, even in advance of that, I have seen different people put together one-off shell scripts or similar that are capable of putting a properly formed entry into the module cache such that it can be used by GOPROXY=file://your/path. For example: https://github.com/komuw/goproxy/blob/master/goproxy.sh#L71
And I have my own (unpublished incomplete and unfinished) code to try doing the same thing. Not elegant code I'm especially proud of, just quick and dirty “get it to work before august” code.
Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/
You can add it to your collection of code that tries to do things with Go modules.
And I should have added, the readme is sparse but the tool should be self documenting, just build cmd/modist and run it, it will output help about available subcommands and their parameters
Regards,
On 3/27/19, 'Nicolas Mailhot' via golang-dev golang-dev@googlegroups.com wrote: ...
Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/
...
And I should have added, the readme is sparse but the tool should be self documenting, just build cmd/modist and run it, it will output help about available subcommands and their parameters
godoc.org/pagure.io/modist/ doesn't seem to work. As far as I can tell, most published go code works automagically with godoc.org. If you plan to look into this, godoc.org/github.com/golang/gddo can be one useful starting point.
Le 2019-03-27 10:25, fgergo@gmail.com a écrit :
On 3/27/19, 'Nicolas Mailhot' via golang-dev golang-dev@googlegroups.com wrote: ...
Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/
...
And I should have added, the readme is sparse but the tool should be self documenting, just build cmd/modist and run it, it will output help about available subcommands and their parameters
godoc.org/pagure.io/modist/ doesn't seem to work. As far as I can tell, most published go code works automagically with godoc.org. If you plan to look into this, godoc.org/github.com/golang/gddo can be one useful starting point.
Thanks for pointing out this. This is something that will probably need looking at, if the code graduates from experiment, and is not deprecated by improvements in upstream go tools.
Right now the priority was just publishing something that builds, to have a concrete application example, and not just abstract exchanges on the mailing list.
Le 2019-03-27 10:44, 'Nicolas Mailhot' via golang-dev a écrit :
Le 2019-03-27 10:25, fgergo@gmail.com a écrit :
On 3/27/19, 'Nicolas Mailhot' via golang-dev golang-dev@googlegroups.com wrote: ...
Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/
...
And I should have added, the readme is sparse but the tool should be self documenting, just build cmd/modist and run it, it will output help about available subcommands and their parameters
godoc.org/pagure.io/modist/ doesn't seem to work. As far as I can tell, most published go code works automagically with godoc.org. If you plan to look into this, godoc.org/github.com/golang/gddo can be one useful starting point.
Thanks for pointing out this. This is something that will probably need looking at, if the code graduates from experiment, and is not deprecated by improvements in upstream go tools.
And, actually, that does not work because godoc.org/github.com/golang/gddo only works with hosting services it has an explicit plugin written for. Which should not surprise me since I have exactly the same limitation in the code I wrote Fedora-side to integrate rpm with hosting platforms (though rpm-side users are free to override definitions if the code does not know the correct one).
On 3/27/19, Nicolas Mailhot nicolas.mailhot@gmail.com wrote:
Le 2019-03-27 10:25, fgergo@gmail.com a écrit :
On 3/27/19, 'Nicolas Mailhot' via golang-dev golang-dev@googlegroups.com wrote: ...
Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/
...
And I should have added, the readme is sparse but the tool should be self documenting, just build cmd/modist and run it, it will output help about available subcommands and their parameters
godoc.org/pagure.io/modist/ doesn't seem to work. As far as I can tell, most published go code works automagically with godoc.org. If you plan to look into this, godoc.org/github.com/golang/gddo can be one useful starting point.
Thanks for pointing out this. This is something that will probably need looking at, if the code graduates from experiment, and is not deprecated by improvements in upstream go tools.
Right now the priority was just publishing something that builds, to have a concrete application example, and not just abstract exchanges on the mailing list.
(This is still only about sharing go code.) I wasn't sure if I should add or not, but since you reiterated that you intend to make others check out the published code: you'll most probably have a wider audience if or when the reason for the code is in the documentation and it's available via a familiar mechanism.
golang@lists.fedoraproject.org
-
fgergo＠gmail.com -
Nicolas Mailhot