From owner-freebsd-ruby@freebsd.org Tue Sep 17 06:40:43 2019 Return-Path: Delivered-To: freebsd-ruby@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 78B09F93C1 for ; Tue, 17 Sep 2019 06:40:43 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46XYQg2YT9z4bYP for ; Tue, 17 Sep 2019 06:40:43 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 53A8FF93C0; Tue, 17 Sep 2019 06:40:43 +0000 (UTC) Delivered-To: ruby@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 530F7F93BE; Tue, 17 Sep 2019 06:40:43 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46XYQg1PQTz4bYM; Tue, 17 Sep 2019 06:40:43 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from mail.j.mat.cc (owncloud.cube.mat.cc [79.143.240.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.mat.cc", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: mat/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D81921364F; Tue, 17 Sep 2019 06:40:42 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from atuin.in.mat.cc (unknown [IPv6:2a01:678:42:ffff:3e15:c2ff:fec4:452e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mat@mat.cc) by mail.j.mat.cc (Postfix) with ESMTPSA id 78D1F942D80; Tue, 17 Sep 2019 06:40:40 +0000 (UTC) Date: Tue, 17 Sep 2019 08:40:39 +0200 From: Mathieu Arnold To: Koichiro Iwao Cc: Adam Weinberger , FreeBSD Ports , ruby@freebsd.org Subject: Re: FLAVORS for Ruby Message-ID: <20190917064039.7qhnw3lds2zaxdl5@atuin.in.mat.cc> References: <20190913074519.xfu3avb4ihmfzm2o@icepick.vmeta.jp> <20190913090645.buutinhgh2pygb4h@icepick.vmeta.jp> <20190914042738.r3hedyqtpxsxnd5e@icepick.vmeta.jp> <006FCB74-04EB-4A82-A800-6C7CA273E749@adamw.org> <20190916143929.z6vnzoqjme6vw2ey@icepick.vmeta.jp> <20190916161650.4ofb2o27tfxif57e@icepick.vmeta.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ezlm5sg6hqdmgwqe" Content-Disposition: inline In-Reply-To: <20190916161650.4ofb2o27tfxif57e@icepick.vmeta.jp> User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-ruby@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD-specific Ruby discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 06:40:43 -0000 --ezlm5sg6hqdmgwqe Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2019 at 01:16:50AM +0900, Koichiro Iwao wrote: > On Mon, Sep 16, 2019 at 08:54:17AM -0600, Adam Weinberger wrote: > > On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao wrote: > > > > > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > > > The issue is that FLAVORS has added a substantial (and painful) com= plexity to python ports and python.mk. It means that a number of people hav= e had to be hyper-vigilant and watch commits closely to catch errors introd= uced when people utilize the paradigm incorrectly. It=E2=80=99s a bitter pi= ll, but it=E2=80=99s accepted because the use-case for multiple concurrent = python versions is essential. > > > > > > > > As Antoine said, inconsistency isn=E2=80=99t a strong enough use ca= se. Which brings us back to the original question: is there a specific use-= case for concurrent ruby that makes the substantial increase in cognitive l= oad, complexity, and monitoring worth it? > > > > > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versio= ns > > > is essential? > >=20 > > We're going in circles here. I've for the third time now that what > > we'd need to get on board is a use case, a description of the end-user > > problem that we're trying to solve. > >=20 > > What you've provided (for the fourth time in this thread) is a straw > > man argument. What other languages have is irrelevant. We are much > > less concerned with "consistency" than with solving end-user problems > > in a way that fits the specific use case. > >=20 > > Steve seemed interested in the idea. I'd explore it with him, and I > > hope you are able to make it happen. I'm done here. >=20 > Thanks. I see a gap between you and me but I'll give it a try anyway > with swills. >=20 > You: If there's no valid reasons, don't do it. > Me: If there's no invalid reasons, try it. >=20 > I believe that the reason Ruby don't have FLAVORS is just nobody worked > on that. In fact, swills worked on that a little. >=20 > BTW, if I can do something only necessary, what a boring life. What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? The answer cannot be "because it should be fun" or "there is no reason there should not be". Give us a real reason about why it would be required. --=20 Mathieu Arnold --ezlm5sg6hqdmgwqe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEOraXidLtEhBkQLpbOkUW81GDzkgFAl2Af+ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNB QjY5Nzg5RDJFRDEyMTA2NDQwQkE1QjNBNDUxNkYzNTE4M0NFNDgACgkQOkUW81GD zkjsYA/+KkjAuBH227F8RKYFD/Wa99Jzfy+gEfdw0u9uoCYgY6oMXZmQr+M/eqHF /QfH+g0/pENsPAkJs0jA8AZsk5+aEPeaPGnUpiKRXxvsJVpqSiWqXKxQykZsZizU k8mcyt56ts8lAmg6lWkgeKpO2TUwAp5u/fQogoacRPORVqNlN8eAhkM9nl0zttoz kq8koan1dlZEcA8mR7ow4HlXqW1a0/Fd22YrKBzYcnXxF0Trojm/xH56q3ToAw/K uGMu9KZnxfeNLV+6jjwlZYEsWDqR9ig6o25P6q7oFlKd7Z1uHypMKMuvARkxEi7/ yGlJq4bC0ffVwtwNM5I/KzhdZLfLHl/fodcMLNWNPOeVLFV/EdHMcpXJJ6RrTKUs 8LhAwcbjrk5q5g2jXtGkwOexvMZ+tinskwobvOwAFbzgas+9qjMbBn2edXq2iwUP JaJv7OAzTMVHfj3iDdtelVjxOQaaGZuQbjPJEAK8xqnAMv45i9gG8EWeVzKxNPc9 vx/tVf2jCt9+Oyr2J2PSdVcOKizh706TRyV8WmYrr275ovXrF8vVS5i+hoBreocS 34oC1rNLjV2eUOaY6GNApuEe7HPKo8jm8N03OFq/2iMkXS5xoMQGNsNil72hq+16 NlMBPTPnseY6CAxHtMyfJV8xycjOR9Wb5fShNogDC5MqHnAvu94= =n3+o -----END PGP SIGNATURE----- --ezlm5sg6hqdmgwqe--