Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Date: Mon, 16 Sep 2019 19:19:46
Message-Id: 3baec351c4936a5cd745fad5eb9f9312d4480aaa.camel@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules by William Hubbs
1 On Mon, 2019-09-16 at 13:46 -0500, William Hubbs wrote:
2 > On Mon, Sep 16, 2019 at 08:05:50PM +0200, Michał Górny wrote:
3 > > On Mon, 2019-09-16 at 09:17 -0500, William Hubbs wrote:
4 > > > Signed-off-by: William Hubbs <williamh@g.o>
5 > > > ---
6 > > > eclass/go-module.eclass | 117 ++++++++++++++++++++++++++++++++++++++++
7 > > > 1 file changed, 117 insertions(+)
8 > > > create mode 100644 eclass/go-module.eclass
9 > > >
10 > > > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
11 > > > new file mode 100644
12 > > > index 00000000000..7e16ec4e95c
13 > > > --- /dev/null
14 > > > +++ b/eclass/go-module.eclass
15 > > > @@ -0,0 +1,117 @@
16 > > > +# Copyright 2019 gentoo authors
17 > > > +# Distributed under the terms of the GNU General Public License v2
18 > > > +
19 > > > +# @ECLASS: go-module.eclass
20 > > > +# @MAINTAINER:
21 > > > +# William Hubbs <williamh@g.o>
22 > > > +# @SUPPORTED_EAPIS: 7
23 > > > +# @BLURB: basic eclass for building software written in the go
24 > > > +# programming language that uses go modules.
25 > > > +# @DESCRIPTION:
26 > > > +# This eclass provides some basic things needed by all software
27 > > > +# written in the go programming language that uses go modules.
28 > > > +#
29 > > > +# You will know the software you are packaging uses modules because
30 > > > +# it will have files named go.sum and go.mod in its top-level source
31 > > > +# directory. If it does not have these files, use the golang-* eclasses.
32 > >
33 > > Please add a big fat warning around here somewhere that people need to
34 > > look through LICENSE files in all vendored modules, and list them
35 > > in LICENSE. They also need to watch out for license conflicts.
36 > >
37 > > > +#
38 > > > +# If the software you are packaging uses modules, the next question is
39 > > > +# whether it has a directory named "vendor" at the top-level of the source tree.
40 > > > +#
41 > > > +# If it doesn't, you need to create a tarball of what would be in the
42 > > > +# vendor directory and mirror it locally.
43 > > > +# If foo-1.0 is the name of your project and you have the tarball for it
44 > > > +# in your current directory, this is done with the following commands:
45 > > > +#
46 > > > +# @CODE:
47 > > > +#
48 > > > +# tar -xf foo-1.0.tar.gz
49 > > > +# cd foo-1.0
50 > > > +# go mod vendor
51 > > > +# cd ..
52 > > > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
53 > > > +#
54 > > > +# @CODE:
55 > > > +
56 > > > +# If we uncomment src_prepare below, the last two lines in the above
57 > > > +# code block are reduced to one:
58 > > > +#
59 > > > +# @CODE:
60 > > > +#
61 > > > +# tar -acf foo-1.0-vendor.tar.gz vendor
62 > > > +#
63 > > > +# @CODE:
64 > > > +
65 > > > +case ${EAPI:-0} in
66 > > > + 7) ;;
67 > > > + *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
68 > > > +esac
69 > > > +
70 > > > +if [[ -z ${_GO_MODULE} ]]; then
71 > > > +
72 > > > +_GO_MODULE=1
73 > > > +
74 > > > +BDEPEND=">=dev-lang/go-1.12"
75 > > > +
76 > > > +# The following go flags should be used for all go builds.
77 > > > +# -mod=vendor stopps downloading of dependencies from the internet.
78 > > > +# -v prints the names of packages as they are compiled
79 > > > +# -x prints commands as they are executed
80 > > > +export GOFLAGS="-mod=vendor -v -x"
81 > > > +
82 > > > +# Do not complain about CFLAGS etc since go projects do not use them.
83 > > > +QA_FLAGS_IGNORED='.*'
84 > > > +
85 > > > +# Go packages should not be stripped with strip(1).
86 > > > +RESTRICT="strip"
87 > > > +
88 > > > +# EXPORT_FUNCTIONS src_prepare pkg_postinst
89 > > > + EXPORT_FUNCTIONS pkg_postinst
90 > > > +
91 > > > +# @FUNCTION: go-module_src_prepare
92 > > > +# @DESCRIPTION:
93 > > > +# Run a default src_prepare then move our provided vendor directory to
94 > > > +# the appropriate spot if upstream doesn't provide a vendor directory.
95 > > > +#
96 > > > +# This is commented out because I want to see where the discussion on
97 > > > +# the ml leads.
98 > > > +# Commenting it out and following the above instructions means that you
99 > > > +# are forced to manually re-tar the vendored dependencies for every
100 > > > +# version bump.
101 > > > +# Using the previous method, it would be possible to decide if you need
102 > > > +# to do this by comparing the contents of go.mod in the previous and new
103 > > > +# version.
104 > > > +# Also, note that we can generate a qa warning if a maintainer forgets
105 > > > +# to drop the vendor tarball and upstream starts vendoring.
106 > > > +# go-module_src_prepare() {
107 > > > +# default
108 > > > +# # If upstream vendors the dependencies and we provide a vendor
109 > > > +# # tarball, generate a qa warning.
110 > > > +# if [[ -d vendor ]] && [[ -d ../vendor ]] ; then
111 > > > +# eqawarn "This package's upstream source includes a vendor
112 > > > +# eqawarn "directory and the maintainer provides a vendor tarball."
113 > > > +# eqawarn "Please report this on https://bugs.gentoo.org"
114 > >
115 > > Why aren't you making it fatal?
116 >
117 > I didn't make it fatal because it doesn't break the build. The build
118 > will ignore the ../vendor directory from the tarball since it is not
119 > under ${S}. Do you want it to be fatal?
120 >
121
122 Yes, it's ebuild author's mistake and there is no point why such mistake
123 should be committed.
124
125 --
126 Best regards,
127 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature