From owner-freebsd-ports@freebsd.org Wed Apr 19 02:59:15 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7548DD45449 for ; Wed, 19 Apr 2017 02:59:15 +0000 (UTC) (envelope-from christopherhall.hsw@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 52068F6C for ; Wed, 19 Apr 2017 02:59:15 +0000 (UTC) (envelope-from christopherhall.hsw@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5165BD45448; Wed, 19 Apr 2017 02:59:15 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5108AD45447 for ; Wed, 19 Apr 2017 02:59:15 +0000 (UTC) (envelope-from christopherhall.hsw@gmail.com) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 20BE2F6B for ; Wed, 19 Apr 2017 02:59:15 +0000 (UTC) (envelope-from christopherhall.hsw@gmail.com) Received: by mail-pf0-x244.google.com with SMTP id a188so1670909pfa.2 for ; Tue, 18 Apr 2017 19:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ScyaS9KTJaEkLtuf2b1xv8Iz73Cp15b0ueLAEYWb428=; b=jOGuvXa5yB1caGiDzpQLGchf29ukXOjLYZ/SBsIAM4TJNhivaFV32b5883oLydzheU 50iC+yu8iNNUnAENncikoLhiDgfXa6zkU2INxUvVQCMAos+d/epuOPvfVKDaOBxg/p0u enaLhQrp/Ti7eSjliF6Be5MZ8WwsE54ZDjrM9fnynYJQOhEqvacpQ4lAh1A/oaWJyTNe MwrLR3v6vAqScB9wyvgHcys7h+bnAoNcbdXQO0FkLDwNkW9+PbnCXAhudtkUAurFZsiW cMiu7HoxhjAwswzQkIAy/nlx10MeihDTR7kTLGUtN9TJmF/KfCRx80Agw0HcrniPF66d w59A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ScyaS9KTJaEkLtuf2b1xv8Iz73Cp15b0ueLAEYWb428=; b=tCJYtjnfPnUNdmCQjlOV+3yKWadEJwin/M9cf/F/KDxdVQlU62R7P/PkSBh7+Ja1QZ QPk2rQkDK5T5fUBFf8o9750jTgroHc5+dod4XKuZSzDxnK3dazbjoBzyFvsz+/gvgc1v zoIOkZThcYlAFz9jqvhu/X8UZfGneFjRme8ohNliesih1VDo71YDNQ5tWSrXslTFE33f QO/FBxwXqZhNHD7a3LS3pdGsDOG+MzpziKCkFVYwmfaA0n0WUo4uLqO0tQph6CBaG5oR otkQL7mdjEnwVyeZ+3ZECe6EpNBC7EE61GryuPku9fZg80qdhfAvsKVv6TuTxY4vFfWL LaJw== X-Gm-Message-State: AN3rC/7bCONJuDtW0vDszEsXsP7i2ZmaX3xPGOosn6BrIo/aISaeYlqh wr2/ihaeDTO96g== X-Received: by 10.99.127.70 with SMTP id p6mr676089pgn.169.1492570754610; Tue, 18 Apr 2017 19:59:14 -0700 (PDT) Received: from arria.bitmark.lan ([2001:b030:2314:200:f279:59ff:fe6a:4741]) by smtp.gmail.com with ESMTPSA id 74sm929688pfn.102.2017.04.18.19.59.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 18 Apr 2017 19:59:14 -0700 (PDT) Date: Wed, 19 Apr 2017 10:59:10 +0800 From: Christopher Hall To: Steven Hartland Cc: ports@freebsd.org Subject: Re: Packaging Go Libs Message-ID: <20170419105910.3b87a7a6@arria.bitmark.lan> In-Reply-To: References: <20170418103350.433498f4@arria.bitmark.lan> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 02:59:15 -0000 Hello Steven, On Tue, 18 Apr 2017 13:09:22 +0000, Steven Hartland wrote: > You should use built in golang vendoring to ensure these > dependencies, as their is no guarantee that someone won't update the > library port and your app would break, so doing that is very fragile Currently the GH_TUPLE method is working as it specifies exact dependency versions or specific git hashes. but we made several attempts at submodules in vendor dir but have had problems building and go get -u breaks things. I am wondering if you might suggest a tool or do any other programs in ports use such a dependency tool. Last time I searched ports tree I only saw GH_TUPLE used so I just followed that method. > On Tue, 18 Apr 2017 at 03:34, Christopher Hall < > christopherhall.hsw@gmail.com> wrote: > > > Hello Steve, > > > > On Mon, 17 Apr 2017 10:20:20 -0400, Steve Wills > > wrote: > > > Hi, > > > > > > I'd like to propose eliminating packaging of Go libs. > > > > For my own go application I use the ports mechanism to specify > > specific versions of dependencies and it would only have been > > tested with those; if forces to use an older version it would > > likely fail as the APIs on some libs have changed quite a lot. > > > > So I personally see no need to have any go dependencies in the ports > > tree. I currently like the idea of having all the go dependencies > > statically linked and only few external "C" libs as dynamic links > > as it makes packaging and deployment very quick. > > > > > > > > Almost every Go app is developed with a different version of any > > > given lib than what another Go app might use. Forcing a Go app to > > > use a different version than what upstream might have chosen is > > > error prone at best and likely to produce a build that's > > > unsupported upstream. So for the packaged libs to even be useful, > > > we would have to have as many versions of each lib as there are > > > consumers, or nearly as many. > > > > > > Further, best practice in the Go community is for Go apps to > > > vendor all their dependencies and almost all apps do that. This > > > is the reason most Go apps use different versions of it's libs. > > > > > > So to me, packaging Go libs doesn't make sense and I think we > > > should remove the Go libs from ports. > > > > > > Existing ports which use the Go libs should be updated to not use > > > the Go lib ports by doing one of these, in priority order: > > > > > > * Converted to using vendored deps included with the package > > > source if possible (preferred) > > > * Fetching the versions of deps specified by upstream (in the > > > case of vendor.json) > > > * As a last resort (deps are not included nor versions specified > > > exactly) fetching versions of deps available at the time of > > > upstream development > > > > > > Further, documentation should be added to the Porters Handbook > > > saying that we don't package Go libs and portlint should be > > > updated to check for installing files in GO_SRCDIR and GO_LIBDIR > > > (exceot lang/go*). > > > > > > For reference, here's the list of Go lib ports that I found at the > > > moment: > > > > > > archivers/go-compress > > > databases/gomdb > > > databases/gosqlite3 > > > databases/levigo > > > databases/radix.v2 > > > databases/redigo > > > devel/go-bayesian > > > devel/go-cobra > > > devel/go-codec > > > devel/go-cpuid > > > devel/go-crc32 > > > devel/go-faker > > > devel/go-form > > > devel/go-go.uuid > > > devel/go-goregen > > > devel/go-hashicorp-logutils > > > devel/go-json-rest > > > devel/go-logrus > > > devel/go-metrics > > > devel/go-nuid > > > devel/go-pflag > > > devel/go-protobuf > > > devel/go-raw > > > devel/go-runewidth > > > devel/go-slices > > > devel/go-sql-driver > > > devel/go-uuid > > > devel/go-yaml > > > devel/goprotobuf > > > net/go-amqp > > > net/go-geoip > > > net/go-httppath > > > net/go-httptreemux > > > net/go-nats > > > net/go.net > > > security/go.crypto > > > security/goptlib > > > textproc/go.text > > > www/go-fasthttp > > > www/webgo > > > > > > Does anyone have any objection or reasoning why this doesn't make > > > sense? > > > > > > Thanks, > > > Steve > > > > > > > > > -- > > Best Regards. > > Christopher Hall. > > _______________________________________________ > > freebsd-ports@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to > > "freebsd-ports-unsubscribe@freebsd.org" -- Best Regards. Christopher Hall.