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.

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

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

Mathieu Arnold

Attachment: signature.asc
Description: PGP signature

Reply via email to