On 2020/07/27 23:11, Kubilay Kocak wrote: > On 28/07/2020 12:29 pm, John W. O'Brien wrote: >> On 2020/07/27 22:08, Kubilay Kocak wrote: >>> On 28/07/2020 5:43 am, John W. O'Brien wrote: >>>> Greetings FreeBSD Python, >>>> >>>> I have been mulling over a thing and would like the list's perspective >>>> before I decide whether to take action or not. >>>> >>>> security/py-pycryptodome will use devel/py-cffi if it is available [0] >>>> or ctypes otherwise [1]. This makes me just a little bit uneasy >>>> since it >>>> leaves the door open to certain Heisenbugs and red herrings. My >>>> question >>>> is whether it warrants adding devel/py-cffi to RUN_DEPENDS to ensure >>>> consistency behavior? If not, what about as an OPTION for those who >>>> care >>>> about that sort of thing? >>>> >>>> [0] >>>> https://github.com/Legrandin/pycryptodome/blob/v3.9.8/lib/Crypto/Util/_raw_api.py#L71-L161 >>>> >>>> >>>> [1] >>>> https://github.com/Legrandin/pycryptodome/blob/v3.9.8/lib/Crypto/Util/_raw_api.py#L163-L263 >>>> >>>> >>>> [2] https://en.wikipedia.org/wiki/Heisenbug >>>> >>> >>> The Python Policy section on optional dependencies should cover this: >>> >>> https://wiki.freebsd.org/Python/PortsPolicy#Optional_Dependencies >>> >>> tldr; >>> >>> For either at build or run-time optional dependencies (where the pattern >>> is, check if dep exists, use some code path if true, else use another >>> code path), add OPTIONS for them. >> >> OK, so something like this? >> >> OPTIONS_DEFINE=CFFI >> OPTIONS_DEFAULT=CFFI >> >> CFFI_DESC=Use devel/py-cffi for low-level API instead of ctypes >> CFFI_RUN_DEPENDS=${PYTHON_PKGNAMEPREFIX}cffi>=0:devel/py-cffi@${PY_FLAVOR} >> > > That's fine. If the option is related to performance, id clarify that in > the description. > >>> Re heisenbugs/etc, this is where support for running test suites in the >>> port are critical, let us know in #freebsd-python on freenode IRC if you >>> need help getting these hooked up >> >> I've been looking forward to the day when [3] lands. Is there some other >> way to run the test target in a poudriere build? > > Yes, that would be nice. The other way is to testport -i to enter the > jail, at which point you can run `make test` from the port dir
Is there any trick to ensuring that the TEST_DEPENDS have already been built, or are already installed in the jail, by that point? >> Of course, running test suites in the build environment wouldn't uncover >> bugs that are triggered by something that just happens to show up in the >> runtime environment. Enabling the OPTIONal things by default would >> clearly help. > > The same as ports defaulting OPTIONS to enabled to benefit package > users, python's optional dependency policy is to do the same, such that > the default port options are the ones that are tested. > > Maintainers can and should do more comprehensive testing by testing > various combinations of PTIONS > >> [3] https://github.com/freebsd/poudriere/pull/355 -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B
signature.asc
Description: OpenPGP digital signature
