Change Details

The patch from the original revision https://reviews.freebsd.org/D36061 was committed after 14 days of no response from python@ and then reverted. As it turned out Charlie Li (vishwin@) has a proposal for a similar feature: https://wiki.freebsd.org/Python/PEP-517 that I wasn't aware of at the time I created the patch. The commit was reverted due to the collision with Charlie Li's proposal. Upon a careful review the proposal https://wiki.freebsd.org/Python/PEP-517 is for a combination of local PEP-517 compliance and global PEP-517 compliance. Local PEP-517 compliance means that individual ports are built with a PEP-517 compliant process. Global PEP-517 compliance means that the whole ports tree is converted to PEP-517 and distutils/setuptools aren't used any longer to build Python ports. It appears that it is best to handle local and global PEP-517 compliance separately due to resource limitations, their different nature, and them being only loosely related. In the first phase local PEP-517 compliance can be implemented, so that individual ports would build according to PEP-517. This would open the way to a lot of new ports to enter the ports tree. Global PEP-517 compliance can be implemented during the second phase. The patch that I am suggesting implements local PEP-517 compliance (the first phase). One difference from the https://reviews.freebsd.org/D36061 proposal is that USE_PYTHON=build is used instead of USE_PYTHON=pep517. "build" is user's intent and is also a very easy to remember word, compared to "pep517" that isn't as easy to remember. The second difference is that USE_PYTHON=build doesn't support the autoplist feature. The involved tools (build/installed) don't support autoplist and it would be unnatural and not in line with the rest of the ports tree to have autoplist just for Python ports. In short: the patch herein is essentially in no contradiction with https://wiki.freebsd.org/Python/PEP-517. It provides 2 above mentioned improvements, and also splits the whole project into 2 largely unconnected parts therefore simplifying the process. I am asking for suggestions on how to improve this patch and seeking approval from python@ and others.

The patch from the original revision https://reviews.freebsd.org/D36061 was committed after 14 days of no response from python@ and then reverted. As it turned out Charlie Li (vishwin@) has a proposal for a similar feature: https://wiki.freebsd.org/Python/PEP-517 that I wasn't aware of at the time I created the patch. The commit was reverted due to the collision with Charlie Li's proposal. Upon a careful review the proposal https://wiki.freebsd.org/Python/PEP-517 is for a combination of local PEP-517 compliance and global PEP-517 compliance. Local PEP-517 compliance means that individual ports are built with a PEP-517 compliant process. Global PEP-517 compliance means that the whole ports tree is converted to PEP-517 and distutils/setuptools aren't used any longer to build Python ports. It appears that it is best to handle local and global PEP-517 compliance separately due to resource limitations, their different nature, and them being only loosely related. In the first phase local PEP-517 compliance can be implemented, so that individual ports would build according to PEP-517. This would open the way to a lot of new ports to enter the ports tree. Global PEP-517 compliance can be implemented during the second phase. The second phase would require a lot of Python ports to be adjusted that would likely take a lot more time. The patch that I am suggesting implements local PEP-517 compliance (the first phase). One difference from the https://reviews.freebsd.org/D36061 proposal is that USE_PYTHON=build is used instead of USE_PYTHON=pep517. "build" is user's intent and is also a very easy to remember word, compared to "pep517" that isn't as easy to remember. The second difference is that USE_PYTHON=build doesn't support the autoplist feature. The involved tools (build/installed) don't support autoplist and it would be unnatural and not in line with the rest of the ports tree to have autoplist just for Python ports. In short: the patch herein is essentially in no contradiction with https://wiki.freebsd.org/Python/PEP-517. It provides 2 above mentioned improvements, and also splits the whole project into 2 largely unconnected parts therefore simplifying the process. I am asking for suggestions on how to improve this patch and seeking approval from python@ and others.

The patch from the original revision https://reviews.freebsd.org/D36061 was committed after 14 days of no response from python@ and then reverted. As it turned out Charlie Li (vishwin@) has a proposal for a similar feature: https://wiki.freebsd.org/Python/PEP-517 that I wasn't aware of at the time I created the patch. The commit was reverted due to the collision with Charlie Li's proposal. Upon a careful review the proposal https://wiki.freebsd.org/Python/PEP-517 is for a combination of local PEP-517 compliance and global PEP-517 compliance. Local PEP-517 compliance means that individual ports are built with a PEP-517 compliant process. Global PEP-517 compliance means that the whole ports tree is converted to PEP-517 and distutils/setuptools aren't used any longer to build Python ports. It appears that it is best to handle local and global PEP-517 compliance separately due to resource limitations, their different nature, and them being only loosely related. In the first phase local PEP-517 compliance can be implemented, so that individual ports would build according to PEP-517. This would open the way to a lot of new ports to enter the ports tree. Global PEP-517 compliance can be implemented during the second phase. The second phase would require a lot of Python ports to be adjusted that would likely take a lot more time. The patch that I am suggesting implements local PEP-517 compliance (the first phase). One difference from the https://reviews.freebsd.org/D36061 proposal is that USE_PYTHON=build is used instead of USE_PYTHON=pep517. "build" is user's intent and is also a very easy to remember word, compared to "pep517" that isn't as easy to remember. The second difference is that USE_PYTHON=build doesn't support the autoplist feature. The involved tools (build/installed) don't support autoplist and it would be unnatural and not in line with the rest of the ports tree to have autoplist just for Python ports. In short: the patch herein is essentially in no contradiction with https://wiki.freebsd.org/Python/PEP-517. It provides 2 above mentioned improvements, and also splits the whole project into 2 largely unconnected parts therefore simplifying the process. I am asking for suggestions on how to improve this patch and seeking approval from python@ and others.