From owner-freebsd-ports@freebsd.org Wed Apr 19 10:15:02 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 87B12D45354 for ; Wed, 19 Apr 2017 10:15:02 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.181]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.teksavvy.com", Issuer "DigiCert High Assurance CA-3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2782F176 for ; Wed, 19 Apr 2017 10:15:01 +0000 (UTC) (envelope-from 482254ac@razorfever.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOFAAvN/dY/0StpUVcGQEBAQEBAQEBAQEBBwEBAQEBgjyBGCcaIAOPd48+AQEBAQEBBQGBIgEDKgGVN4IPLoV2AoN7QRcBAgEBAQEBAQFrKIUWAQU4HiMQCxguOR4TCAEBiggNDq0Oiy4BAQEBBgEBAQEfBYYNgk6CboUjhRkBBJ0sAQGHBI1piF4Qhl2IbIlggUQhAjRLOhQnM4dPJIlKAQEB X-IPAS-Result: A0DOFAAvN/dY/0StpUVcGQEBAQEBAQEBAQEBBwEBAQEBgjyBGCcaIAOPd48+AQEBAQEBBQGBIgEDKgGVN4IPLoV2AoN7QRcBAgEBAQEBAQFrKIUWAQU4HiMQCxguOR4TCAEBiggNDq0Oiy4BAQEBBgEBAQEfBYYNgk6CboUjhRkBBJ0sAQGHBI1piF4Qhl2IbIlggUQhAjRLOhQnM4dPJIlKAQEB X-IronPort-AV: E=Sophos;i="5.37,220,1488862800"; d="scan'208";a="308757426" Received: from 69-165-173-68.dsl.teksavvy.com (HELO mail.razorfever.net) ([69.165.173.68]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2017 06:13:51 -0400 Received: from [127.0.0.1] (mail.razorfever.net [192.168.0.4]) by mail.razorfever.net (8.15.2/8.14.9) with ESMTP id v3JADnjH049508; Wed, 19 Apr 2017 06:13:49 -0400 (EDT) (envelope-from 482254ac@razorfever.net) X-Authentication-Warning: mail.razorfever.net: Host mail.razorfever.net [192.168.0.4] claimed to be [127.0.0.1] Subject: Re: Packaging Go Libs To: freebsd-ports@freebsd.org References: <20170418103350.433498f4@arria.bitmark.lan> <20170419105910.3b87a7a6@arria.bitmark.lan> From: "Derek (freebsd lists)" <482254ac@razorfever.net> Cc: Christopher Hall , Steven Hartland Message-ID: <2b1132e6-522b-abdf-d85b-5ce7aafb37f8@razorfever.net> Date: Wed, 19 Apr 2017 06:13:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170419105910.3b87a7a6@arria.bitmark.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, FROM_STARTS_WITH_NUMS,RP_MATCHES_RCVD autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.razorfever.net 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 10:15:02 -0000 Agree with previous sentiments, and: On 17-04-18 10:59 PM, Christopher Hall 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. > From my point of view, the only thing that should be in the vendor directory on checkout is the version-lock file. This is different for different tools. I have been using gb, as it makes the most sense to me: https://getgb.io/ sysutils/hfm uses this godep is also popular, from what I understand: https://godoc.org/github.com/tools/godep Vendoring changed internally in go with a GO15VENDOREXPERIMENT build environment variable (and then default in 1.6), although I have not yet played with it: https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit ... from the docs, it sounds like it would be compatible with gb from a build standpoint - and you simply could use gb to track, fetch and lock versions in development - the same thing the ports GH_TUPLE covers. What you do when it's not hosted at github, well.... Derek