Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit : > Le 2019-03-13 20:33, [email protected] 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, -- Nicolas Mailhot _______________________________________________ golang mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
