[Bug 224024] DEFAULT_VERSIONS for python and PYTHON_VERSION broken after r455210 (FLAVORS)
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Dec 1 18:43:34 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224024
Bug ID: 224024
Summary: DEFAULT_VERSIONS for python and PYTHON_VERSION broken
after r455210 (FLAVORS)
Product: Ports & Packages
Version: Latest
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: Ports Framework
Assignee: portmgr at FreeBSD.org
Reporter: john at saltant.com
CC: freebsd-ports-bugs at FreeBSD.org, python at FreeBSD.org
My goal
I want to build and manage packages in the spirit of PEP 394, so that I can
maintain concurrent installs of ports for any combination of supported python
versions, one of which may be for the default python version, one of which may
be for the default python2 version, and one of which may be for the default
python3 version. In the past, I have accomplished this by setting
DEFAULT_VERSIONS in /usr/local/etc/poudriere.d/make.conf, and then setting
PYTHON_VERSION in each of /usr/local/etc/poudriere.d/pythonXY-make.conf for XY
in {27,34,35,36}. This yields four different repositories with packages that
can, generally speaking, be installed concurrently.
Problem
This technique stopped working after FLAVORS were introduced in r455210.
To demonstrate
% cat /etc/make.conf
DEFAULT_VERSIONS= python=3.6 python2=2.7 python3=3.6
% cd /usr/ports/devel/py-pandas
% make -V FLAVOR
% make PYTHON_VERSION=python3.4 -V FLAVOR
Expected behavior
% make -V FLAVOR
py36
% make PYTHON_VERSION=python3.4 -V FLAVOR
py34
Observed behavior
% make -V FLAVOR
py27
% make PYTHON_VERSION=python3.4 -V FLAVOR
py27
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the freebsd-python
mailing list