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

>> 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.

>> 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.

freebsd-python@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"

Reply via email to