From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Allen Subject: Re: Design decision behind inputs/native-inputs/propagated-inputs Date: Thu, 21 Jan 2016 11:08:11 -0500 Message-ID: <20160121160811.GA1596@stebalien.com> References: <20160121044909.GA18348@stebalien.com> <877fj32qxy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMHmV-0006K4-RM for help-guix@gnu.org; Thu, 21 Jan 2016 11:08:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMHmU-0004GG-PV for help-guix@gnu.org; Thu, 21 Jan 2016 11:08:19 -0500 Content-Disposition: inline In-Reply-To: <877fj32qxy.fsf@gnu.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: help-guix@gnu.org --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01-21-16, Ludovic Court=C3=A8s wrote: > In short, the distinction between =E2=80=98native-inputs=E2=80=99 and =E2= =80=98inputs=E2=80=99 exists > solely because Guix supports cross-compilation. Otherwise it would be > unneeded. >=20 > Propagated inputs are a way to manually say: =E2=80=9CI want this package= to > automatically pull in those other packages.=E2=80=9D This is necessary i= n the > cases given above. >=20 > Does this clarify the rationale? I believe I understand what they mean and how they solve the problem. My question is more "why autodetect runtime dependencies"? That is, dependencies are currently available at runtime as follows: Type | Run Time ------------------+---------------------------------------------- inputs | autodetect (if referenced) propagated-inputs | always (included in the profile) native-inputs | autodetect (if referenced) However, I can't think of any cases where the following wouldn't suffice: Type | Run Time | In Arch ------------------+----------------------------------+----------- inputs | always | (pseudo-)depends propagated-inputs | always (included in the profile) | depends native-inputs | never | makedepends The key difference being the lack of autodetection in the second case. In words, I can't think of any cases where one *would* want native-inputs at runtime and/or *not* want (non-native) inputs at runtime. I ask because I hate automagic (magical autodetection). To illustrate, given: (package (name "foo") (inputs `(("bar", bar))) (native-inputs `(("baz", baz))) ... ) I know that the default output of bar, will be available at build time but whether or not it remains available at runtime depends on whether or not my package includes the string `/gnu/store/$hash-bar/...` somewhere in its output. Why not just say "bar will be available at runtime and baz will not" (really "baz may not" because it might be an input to another package). --=20 Steven Allen --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWoQJlAAoJEGVqlrqQ0li+kEoP/i0yhCj6pt5waT4m5qkxIwvi OIKTGMezW7DLO3SsmzZtijuf5WNPG1soTodglqTXdb4OPI6Y+PO3Z2BsIhPAUBJQ 1bULteYyBGS1lTlCjeRPd9hFk/VwmOHJrXz4x6xNzn2AgrUOzfcflZLWJewNKdkl 7FSXTLF76D7CcnEecagBxvPFDVjrAu2GX8Mdlz2hX0tr21uIg2UEkR3lOhbwhdcA 2GKnHB/NaaJQI6WQFQtWkgxheHHtQinlU3xPN+jIH0N+Lita+5eaxREdUb5+YJu5 cuuY+jEyyK3xCN0qhNg/RlFFp88EutL7JOpN3wcg8vXYdJ/Qy7q45On7MtufC7I3 hCmA4ZKuK2tsC85uoyBtJ1xbjRdFZkSU+xmm+Ve1g4oZwp2e24cO+LEf3U3uX1yl lXiuS0z+EUuj+3wiVluDdbFDjLuNYN62ACvSS4l3AzpQiR4PPSfzYUDFy7KkvmFg aNViPtEa7tOrAGudLLABo5iWO8bomRG1v9tWeh3dXzBYiOWlhGqbKDfjkLUzST14 2MHvOhhG/Gly7hRhGGmzGJOoYiUEjCAyhgwcELou9I5KUhLvEVykE610kqnLreSF lQ4qOIlpo3GSXl4oJ+T22gru6aBnHNDQZmOXbIRwkKXN4bN9dl/EGnLlegeFxJ5O T7Yj6HRFuDDfKM6ogdj9 =h15U -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY--