Date: Fri, 2 Mar 2018 21:03:15 +1100 From: Kubilay Kocak <koobs@FreeBSD.org> To: Mathieu Arnold <mat@FreeBSD.org> Cc: yuri@freebsd.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, python <python@freebsd.org>, "Tobias C. Berner" <tcberner@freebsd.org> Subject: Re: svn commit: r463374 - head/security/nyx Message-ID: <b34fcdfa-2931-7c89-276f-4580f6cc8f14@FreeBSD.org> In-Reply-To: <20180302094548.23bjlc3v53zt6of5@atuin.in.mat.cc> References: <201803020651.w226ptn3091275@repo.freebsd.org> <6f698e1f-a5d5-2cd7-b2b7-c288a3c65bb6@FreeBSD.org> <6dd4b973-fbcb-8fa8-fb3e-1cece416898f@freebsd.org> <531069af-c0fc-1b2c-0c91-52cd73ba001e@FreeBSD.org> <20180302094548.23bjlc3v53zt6of5@atuin.in.mat.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/2/18 8:45 PM, Mathieu Arnold wrote: > On Fri, Mar 02, 2018 at 07:57:51AM +0000, Kubilay Kocak wrote: >> 1) Assuming what users care about is risky business. >> 2) The 'app vs library' distinction is not sound here. It wasn't sound >> for python package prefixing in the past either. >> 3) The change introduces and increases inconsistency among Python ports >> without an upside, without precluding downsides. > > The downside is more packages, and longer build times. Thus, it was > decided to not flavorize ports that do not provide modules. Posing the upside (for python/freebsd users) as a downside is odd. We signed up to resource utilisation when we decided we'd produce binary packages, and flavors. But that derailment aside, it's also a slippery slope. >> The bottom and most important line however, is that preventing Python >> port flavors from being produced precludes the user from choosing what >> version of the package they may want. > > The dozen people who will really, really want to have a cli supporting > more than one Python version with the non default version can probably > build it themselves. Python pushed for variants/flavors to support the flexibility and choice of python port consumers for a diverse annd complex ecosystem as well as to reduce maintenance/development overhead for port maintainers and the python team. All that is being said is that the special case is not special enough. #PEP20 >> lastly, the only reason the noflavors knob exists is because its not >> terribly pleasant as a developer to have features that cant be disabled, >> and because our framework can't imagine all the possible scenarios where >> a feature may cause issues. > > No, the noflavors knob was added after a failed experiment with the > optsuffix knob, to accomodate ports which do not need flavors, like big > applications that only needs python for small features, or cli that do > not really care which Python version is running them. This is a separate use-case (the exception for which was made for prefixing as well) users care, that software someone does is not in question. ./koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b34fcdfa-2931-7c89-276f-4580f6cc8f14>