Re: [gentoo-dev] [PATCH 2/2] go-module-vendor.eclass: new eclass for go modules that do not vendor
On 9/23/19 5:30 PM, William Hubbs wrote:
>> +# @FUNCTION: go-module-vendor_src_unpack
>> +# @DESCRIPTION:
>> +# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR}
>> +# to their usual locations then extract all archives mentioned in
>> +# ${EGO_VENDOR} to ${S}/vendor.
>> +go-module-vendor_src_unpack() {
>> +local f hash import line repo tarball vendor_uri
>> +if [[ -z "${EGO_VENDOR}" ]]; then
>> +die "EGO_VENDOR is not defined"
>> +fi
>> +
>> +vendor_uri="$(go-module-vendor_get_vendor_uri)"
>> +for f in $A; do
>> +[[ $vendor_uri == *"$f"* ]] && continue
>> +unpack $f
>> +done
>> +
>> +if [[ -d "${S}/vendor" ]]; then
>> +eerror "Upstream for ${P}.ebuild vendors dependencies."
>> +die "This ebuild should inherit go-module.eclass"
>> +fi
>
> All,
>
> I want to talk about the if block just above where I am writing.
>
> If the vendor directory exists after the sources are unpacked, the idea
> is that upstream is vendoring their dependencies and we probably don't
> want to mess with the contents of the vendor directory in that case.
>
> Mgorny, you suggested that there might be a valid use case for being
> able to insert our own dependencies even when upstream bundles them for
> security. Something like that is an easy enough change (deleting the if
> block), but I want to know more about whether this is a strong case for
> it. My thought is that if the issue is reported to upstream, they should
> do a new release after updating their vendored dependencies, so this is
> more an upstream thing.
>
> Thoughts? Is there a strong enough use case for messing with the bundled
> dependencies ourself?
If you feel like it would add unnecessary complexity, then it's probably
fine to leave that case unsupported. The worst case is that ebuild
maintainers will have to copy and modify the eclass function.
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/2] go-module-vendor.eclass: new eclass for go modules that do not vendor
On Mon, Sep 23, 2019 at 06:36:49PM -0500, William Hubbs wrote:
> This eclass adds a src_unpack function that supports the EGO_VENDOR
> variable for vendoring modules.
> ---
> eclass/go-module-vendor.eclass | 124 +
> 1 file changed, 124 insertions(+)
> create mode 100644 eclass/go-module-vendor.eclass
>
> diff --git a/eclass/go-module-vendor.eclass b/eclass/go-module-vendor.eclass
> new file mode 100644
> index 000..ceb362d89ba
> --- /dev/null
> +++ b/eclass/go-module-vendor.eclass
> @@ -0,0 +1,124 @@
> +# Copyright 2019 gentoo authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: go-module-vendor.eclass
> +# @MAINTAINER:
> +# William Hubbs
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: Eclass for building software written in the go
> +# programming language that uses go modules and does not vendor.
> +# @DESCRIPTION:
> +# This eclass provides a src_unpack function which supports vendoring
> +# dependencies for software written in the go programming language that
> +# uses go modules.
> +#
> +# You will know the software you are packaging uses modules because
> +# it will have files named go.sum and go.mod in its top-level source
> +# directory. If it does not have these files, use the golang-* eclasses.
> +#
> +# If there is also a directory named vendor in the top level source directory
> +# of your package, use the golang-module eclass instead of this one.
> +#
> +# This eclass provides a src_unpack function which unpacks the
> +# first tarball mentioned in SRC_URI to ${S} and unpacks any modules
> +# mentioned in EGO_VENDOR to ${S}/vendor.
> +#
> +# Please note that this eclass currently handles only tarballs
> +# (.tar.gz), but support for more formats may be added in the future.
> +#
> +# Since Go programs are statically linked, it is important that your ebuild's
> +# LICENSE= setting includes the licenses of all statically linked
> +# dependencies. So please make sure it is accurate.
> +#
> +# @EXAMPLE:
> +#
> +# @CODE
> +# inherit go-module-vendor
> +#
> +# EGO_VENDOR=(
> +#"github.com/xenolf/lego 6cac0ea7d8b28c889f709ec7fa92e92b82f490dd"
> +# "golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8
> github.com/golang/crypto"
> +# )
> +#
> +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> ${P}.tar.gz
> +# $(go-module-vendor_get_vendor_uri)"
> +# @CODE
> +
> +inherit go-module
> +
> +case ${EAPI:-0} in
> + 7) ;;
> + *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> +esac
> +
> +if [[ -z ${_GO_MODULE_VENDOR} ]]; then
> +
> +_GO_MODULE_VENDOR=1
> +
> +EXPORT_FUNCTIONS src_unpack
> +
> +# @ECLASS-VARIABLE: EGO_VENDOR
> +# @REQUIRED
> +# @DESCRIPTION:
> +# This variable contains a list of vendored packages.
> +# The items of this array are strings that contain the
> +# import path and the git commit hash for a vendored package.
> +# If the import path does not start with github.com, the third argument
> +# can be used to point to a github repository.
> +
> +# @FUNCTION: go-module-vendor_get_vendor_uri
> +# @DESCRIPTION:
> +# Convert the information in EGO_VENDOR to a format suitable for
> +# SRC_URI.
> +# A call to this function should be added to SRC_URI in your ebuild.
> +go-module-vendor_get_vendor_uri() {
> + local hash import line repo
> + for line in "${EGO_VENDOR[@]}"; do
> + read -r import hash repo _ <<< "${line}"
> + if [[ -n ${repo} ]]; then
> + echo "https://${repo}/archive/${hash}.tar.gz ->
> ${repo//\//-}-${hash}.tar.gz"
> + else
> + echo "https://${import}/archive/${hash}.tar.gz ->
> ${import//\//-}-${hash}.tar.gz"
> + fi
> + done
> +}
> +
> +# @FUNCTION: go-module-vendor_src_unpack
> +# @DESCRIPTION:
> +# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR}
> +# to their usual locations then extract all archives mentioned in
> +# ${EGO_VENDOR} to ${S}/vendor.
> +go-module-vendor_src_unpack() {
> + local f hash import line repo tarball vendor_uri
> + if [[ -z "${EGO_VENDOR}" ]]; then
> + die "EGO_VENDOR is not defined"
> + fi
> +
> + vendor_uri="$(go-module-vendor_get_vendor_uri)"
> + for f in $A; do
> + [[ $vendor_uri == *"$f"* ]] && continue
> + unpack $f
> + done
> +
> + if [[ -d "${S}/vendor" ]]; then
> + eerror "Upstream for ${P}.ebuild vendors dependencies."
> + die "This ebuild should inherit go-module.eclass"
> + fi
All,
I want to talk about the if block just above where I am writing.
If the vendor directory exists after the sources are unpacked, the idea
is that upstream is vendoring their dependencies and we probably don't
want to mess with the contents of the vendor directory in that case.
Mgorny, you suggested that there might be a valid use case for being
able to insert our own dependencies even when upstream bundles them for
Re: [gentoo-dev] [PATCH 2/2] go-module-vendor.eclass: new eclass for go modules that do not vendor
On Sat, 2019-09-21 at 17:10 -0500, William Hubbs wrote:
> This eclass adds a src_unpack function that supports the EGO_VENDOR
> variable for vendoring modules.
> ---
> eclass/go-module-vendor.eclass | 133 +
> 1 file changed, 133 insertions(+)
> create mode 100644 eclass/go-module-vendor.eclass
>
> diff --git a/eclass/go-module-vendor.eclass b/eclass/go-module-vendor.eclass
> new file mode 100644
> index 000..af9007df411
> --- /dev/null
> +++ b/eclass/go-module-vendor.eclass
> @@ -0,0 +1,133 @@
> +# Copyright 2019 gentoo authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: go-module-vendor.eclass
> +# @MAINTAINER:
> +# William Hubbs
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: Eclass for building software written in the go
> +# programming language that uses go modules and does not vendor.
> +# @DESCRIPTION:
> +# This eclass provides a src_unpack function which supports vendoring
> +# dependencies for software written in the go programming language that
> +# uses go modules.
> +#
> +# You will know the software you are packaging uses modules because
> +# it will have files named go.sum and go.mod in its top-level source
> +# directory. If it does not have these files, use the golang-* eclasses.
> +#
> +# If there is also a directory named vendor in the top level source directory
> +# of your package, use the golang-module eclass instead of this one.
> +#
> +# This eclass provides a src_unpack function which unpacks the
> +# first tarball mentioned in SRC_URI to the usual location and unpacks
> +# any modules mentioned in EGO_VENDOR to ${S}/vendor.
> +#
> +# Please note that this eclass currently handles only tarballs
> +# (.tar.gz), but support for more formats may be added in the future.
> +#
> +# Since Go programs are statically linked, it is important that your ebuild's
> +# LICENSE= setting includes the licenses of all statically linked
> +# dependencies. So please make sure it is accurate.
> +#
> +# @EXAMPLE:
> +#
> +# @CODE
> +# EGO_VENDOR=(
> +#"github.com/xenolf/lego 6cac0ea7d8b28c889f709ec7fa92e92b82f490dd"
> +# "golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8
> github.com/golang/crypto"
> +# )
> +#
> +# inherit go-module-vendor
> +#
> +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> ${P}.tar.gz
> +# ${EGO_VENDOR_URI}"
> +# @CODE
> +#
> +# The above example will extract the tarball to ${S} and
> +# extract the contents of EGO_VENDOR to ${S}/vendor.
> +
> +inherit go-module
> +
> +case ${EAPI:-0} in
> + 7) ;;
> + *) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> +esac
> +
> +if [[ -z ${_GO_MODULE_VENDOR} ]]; then
> +
> +_GO_MODULE_VENDOR=1
> +
> +EXPORT_FUNCTIONS src_unpack
> +
> +# @ECLASS-VARIABLE: EGO_VENDOR
You want @REQUIRED here.
> +# @DESCRIPTION:
> +# This variable contains a list of vendored packages.
> +# The items of this array are strings that contain the
> +# import path and the git commit hash for a vendored package.
> +# If the import path does not start with github.com, the third argument
> +# can be used to point to a github repository.
> +
> +declare -arg EGO_VENDOR
> +
> +_go-module-vendor_set_vendor_uri() {
I think you ought to check whether EGO_VENDOR_URI is non-empty here,
and error out if it's empty. This will be important in catching people
accidentally defining it after 'inherit'.
Another thing worth considering is to actually permit defining it
anywhere. If you replaced EGO_VENDOR_URI with a function, user would
only need to define it prior to SRC_URI, e.g.:
inherit go-module-vendor
# ...
EGO_VENDOR_URI=(...)
SRC_URI="...
$(ego_vendor_uri)"
But it's up to you. I personally feel like very long lists prior to
inherit are inconvenient for the reader.
> + EGO_VENDOR_URI=
> + local lib
> + for lib in "${EGO_VENDOR[@]}"; do
> + lib=(${lib})
> + if [[ -n ${lib[2]} ]]; then
> + EGO_VENDOR_URI+="
> https://${lib[2]}/archive/${lib[1]}.tar.gz ->
> ${lib[2]//\//-}-${lib[1]}.tar.gz"
> + else
> + EGO_VENDOR_URI+="
> https://${lib[0]}/archive/${lib[1]}.tar.gz ->
> ${lib[0]//\//-}-${lib[1]}.tar.gz"
> + fi
> + done
> + readonly EGO_VENDOR_URI
> +}
> +
> +_go-module-vendor_set_vendor_uri
> +unset -f _go-module-vendor_set_vendor_uri
> +
> +_go-module-vendor_dovendor() {
> + local VENDOR_PATH=$1 VENDORPN=$2 TARBALL=$3
Common convention is to use lowercase names for local variables.
> + rm -fr "${VENDOR_PATH}/${VENDORPN}" || die
> + mkdir -p "${VENDOR_PATH}/${VENDORPN}" || die
> + tar -C "${VENDOR_PATH}/${VENDORPN}" -x --strip-components 1\
Add space before `\`.
> + -f "${DISTDIR}/${TARBALL}" || die
> +}
> +
> +# @FUNCTION: go-module-vendor_src_unpack
> +# @DESCRIPTION:
> +# Extract the first archive from ${A} to ${S}, then extract
> +# any sources mentioned in ${EGO_VENDOR} to
