After the FLAVOR change I think there are a couple of things that still need to be addressed that affect concurrent python port installs. As package repos now have two flavours for many python ports, trying to install one using the pkg origin will break the install due to conflicts.
1. USE_PYTHON=concurrent should be considered a default option, or part of implementing flavour, maybe have noconcurrent if a port specifically doesn't need it.
2. Using concurrent still has an issue of conflicting man pages, see bug #220214 as a possibile solution for this.
3. If a port is python3 only then no default scripts exist, only the versioned script is created. See bug #216479.
4. Would it be possible for pkg to record the package flavour so that it can be queried? Maybe even a config option to control what flavours it will install?
4: pkg records the package flavors as an annotation:
$ pkg info py27-six
flavor : py27
3: I'm working on it being "the first flavor" and not "the default version"
2: It needs to be fixed, I have not had time to work on it yet.
1: That is over to python@.
I don't think concurrent should be default, it *does* break some ports.
A commit references this bug:
Date: Mon Dec 11 12:41:56 UTC 2017
New revision: 456026
Make USE_PYTHON=concurrent flavors friendly.
Before, it would only create the default symlink if the Python version
was the default Python version. Change that to if the Python flavor is
the default flavor.
Sponsored by: Absolight
(In reply to Antoine Brodin from comment #2)
> I don't think concurrent should be default, it *does* break some ports.
We are trying to get python ports to build and install for multiple python versions, these concurrent breaks should get resolved as part of the updates to support flavours. My experience with concurrent so far is that most ports only need concurrent added, others need some adjustment for manpages and docs.
If concurrent was enabled as a part of defining FLAVOR then USE_PYTHON=noflavors should also disable concurrent for ports it does break.
Using pkg install with a port origin (or a partial name match) now finds all available flavours, without concurrent this can lead to install issues that can frustrate users and lead to a bad user experience that will only contribute to complaints. I reported this as a separate issue for pkg - bug #224265
(In reply to Shane from comment #4)
My experience is the opposite, some people add concurrent without verifying that it runs and that the depending ports still run correctly.