Bug 226486 - Add USE_PYTHON=app instead of the noflavors option
Summary: Add USE_PYTHON=app instead of the noflavors option
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-09 20:04 UTC by Yuri Victorovich
Modified: 2018-03-09 20:09 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2018-03-09 20:04:57 UTC 
Rationale:
Python ports can be divided into 2 categories: apps and libs. Apps are only usable through executables, and provide no externally usable python modules. Everything else is in libs category.

Multiple packages for py2/py3 should always be built for libs. But for apps the need for separate packages isn't as obvious. It could be argued that they are needed to provide the user choice between python2 and python3. It could also be argued that they aren't needed because one package is sufficient since it provides all needed executables.

Suggestion:
Add USE_PYTHON=app. Ports that are apps should always set USE_PYTHON=app. Framework (python.mk) then will make a choice what is done: 'app' could trigger 'noflavors', or not. The point is that individual ports will be free of this choice, and this will not need to be discussed individually for individual ports.

Additionally, 'concurrent' could be implied when there is no 'app'.
Comment 1 Antoine Brodin freebsd_committer freebsd_triage 2018-03-09 20:09:25 UTC 
- concurrent may break some libs

- end-user may prefer the py27 or the py36 flavor of an app