Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit :
Le 2019-03-13 20:33, thepudds1460(a)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,
--
Nicolas Mailhot