unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* packaging go-ethereum, and ultimately bee (of ethswarm.org)
@ 2021-08-30 21:52 Attila Lendvai
  2021-08-31 10:19 ` Attila Lendvai
  2021-08-31 22:21 ` Maxime Devos
  0 siblings, 2 replies; 9+ messages in thread
From: Attila Lendvai @ 2021-08-30 21:52 UTC (permalink / raw)
  To: guix-devel@gnu.org

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

hello everyone,

it's my first mail here, so let me briefly into myself: i'm a long-time lisper (mostly CL, i'm new to Scheme, although i worked on a scheme-like tiny lisp: https://github.com/attila-lendvai/maru). i'm coming over from NixOS after a few months of loving it as a user, but hating it as a developer. i have packaged bee for NixOS (a client of https://www.ethswarm.org/ written in go), but i got tired of the random, undebuggable obstacles of Nix, especially the implementation of the NixOS module system.

bee depends on go-ethereum (it uses its clef binary to manage the ethereum keys).

so, regarding go-ethereum, i've seen this:

[https://issues.guix.gnu.org/43872](https://issues.guix.gnu.org/43872#3)

the initial conclusion was that the proper way to package a go project is to package the pinned transitive closure of every dependency. there's a go importer now, which is functional/hackable enough that this is not a hopeless task, but... i'm doubtful that it's a good idea to multiply the number of Guix packages by such an endeavor... :)

then Helio Machado proposed something smarter in a later comment:

https://issues.guix.gnu.org/43872#3

IIUC, he proposes a way to instead use the go module system to download all the dependencies, and yet authenticate all the downloaded go code. his work is not merged yet, and i think it's not even ready for merging yet.

now, i'm rather motivated to work on this, maybe even willing to use the go importer and add countless pinned go packages... but is that desirable? is that the ultimate solution/goal? or should i wait until Helio's clever hack is merged? or shall i try to finish up his hack to be merge-ready?

i'd really appreciate some guidance and/or coordination regarding where i should put my energy.

- attila
PGP: 5D5F 45C7 DFCD 0A39

PS: even though Guix has more rough edges from a user perspective, it feels much more natural with my developer hat on. thank you for that experience!

[-- Attachment #2: Type: text/html, Size: 2608 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: packaging go-ethereum, and ultimately bee (of ethswarm.org)
@ 2021-09-01 19:14 Sarah Morgensen
  0 siblings, 0 replies; 9+ messages in thread
From: Sarah Morgensen @ 2021-09-01 19:14 UTC (permalink / raw)
  To: Maxime Devos; +Cc: guix-devel@gnu.org

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

>> > have uses outside go-ethereum, so they can be re-used as dependencies of
>> > new go packages, so over time, having to define many new packages when importing
>> > a go application should become less and less of a problem.
>> > 
>> > (About version pinning: I'm ignoring version incompatibilities here. I don't know
>> > how much of a problem that is in practice ...)
>> 
>> i'm not a go expert at all, but i think it's a rather frequent
>> situation in go land to move a dependency one git commit ahead, only
>> to pick up a bugfix that has just been pushed into its repo.
>
> ... unless you meant this here?  But this seems to imply that version
> incompatibilities typically don't happen (otherwise just picking up
> a bugfix with a single commit doesn't seem plausible), so we can
> typically just use the latest version of the go module in guix, no?

A clarification: a canonical Go module version is supposed to follow
semantic versioning guidelines [0], so anything except a major version
bump is supposed to be backwards-compatible.  This is further supported
by major version suffixes [1], which requires that "[s]tarting with
major version 2, module paths must have a major version suffix like /v2
that maches the major version.  For example, if a module has the path
example.com/mod at v1.0.0, it must have the path example.com/mod/v2 at
version v2.0.0."  Because each Guix package only represents one module
path, and that module path is used in the name of the package, we
*should* be able to update to (and use) any newer minor versions of a
module with no issues.

This doesn't address packages without any canonical versions, of
course...

[0] https://golang.org/ref/mod#versions
[1] https://golang.org/ref/mod#major-version-suffixes

--
Sarah


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-09-03 20:20 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-30 21:52 packaging go-ethereum, and ultimately bee (of ethswarm.org) Attila Lendvai
2021-08-31 10:19 ` Attila Lendvai
2021-08-31 22:21 ` Maxime Devos
2021-09-01 14:29   ` Attila Lendvai
2021-09-01 16:17     ` Maxime Devos
2021-09-03  8:16       ` Attila Lendvai
2021-09-03 16:01         ` Bengt Richter
2021-09-03 19:51           ` Attila Lendvai
  -- strict thread matches above, loose matches on Subject: below --
2021-09-01 19:14 Sarah Morgensen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).