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 _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
