2:42 p.m.
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
3:47 a.m.
New subject: [golang-dev] proposal: public module authentication with the Go
notary
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(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.
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,
--
Nicolas Mailhot
4:25 a.m.
New subject: [golang-dev] proposal: public module authentication with the Go notary
On 3/27/19, 'Nicolas Mailhot' via golang-dev
<golang-dev(a)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.
4:44 a.m.
New subject: [golang-dev] proposal: public module authentication with the Go
notary
Le 2019-03-27 10:25, fgergo(a)gmail.com a écrit :
On 3/27/19, 'Nicolas Mailhot' via golang-dev
<golang-dev(a)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.
--
Nicolas Mailhot
5 a.m.
New subject: [golang-dev] proposal: public module authentication with the Go
notary
Le 2019-03-27 10:44, 'Nicolas Mailhot' via golang-dev a écrit :
Le 2019-03-27 10:25, fgergo(a)gmail.com a écrit :
> On 3/27/19, 'Nicolas Mailhot' via golang-dev
> <golang-dev(a)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).
--
Nicolas Mailhot
5:10 a.m.
New subject: [golang-dev] proposal: public module authentication with the Go notary
On 3/27/19, Nicolas Mailhot <nicolas.mailhot(a)gmail.com> wrote:
Le 2019-03-27 10:25, fgergo(a)gmail.com a écrit :
> On 3/27/19, 'Nicolas Mailhot' via golang-dev
> <golang-dev(a)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.
1855
days inactive
1856
days old
golang@lists.fedoraproject.org
5 comments
2 participants
participants (2)
-
fgergo＠gmail.com -
Nicolas Mailhot