svn commit: r463374 - head/security/nyx
Kubilay Kocak
koobs at FreeBSD.org
Fri Mar 2 10:03:44 UTC 2018
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
More information about the freebsd-python
mailing list