On Wed, Feb 2, 2022 at 8:53 AM Thomas Caswell <[email protected]> wrote: > > I disagree with point (3). > > I think it would be better to discourage projects from including the output > of cython in their sdists. They should either have cython as a build-time > requirement or provide built wheels (which are specific a platform and > CPython version). The middle ground of not expecting the user to have cython > while expecting them to have a working c-complier is a very narrow case and I > think asking those users to install cython is worth the forward compatibility > for Python versions you get by requiring people installing from source to > re-cythonize. >
I don't think having C compiler but not cython is the "narrow" case. Requiring the latest Cython is installed is heavy additional dependency. Note that we don't require the latest C compiler. Users may install C compiler via tools like `dnf` or `apt`. But they can not install the latest Cython via `dnf` or `apt`. So this should be considered case-by-case basis. * If the project can provide wheels for very wide platforms, stop bundling C source is not a big problem. * If the project can not provide wheels for some reason (*), they want to bundle C source. * They can release source package more than a year. * Or they want to use "only public API" mode for better compatibility. (*) For example, my "mysqlclient" library provide wheel only on Windows because user may want to use own libmysqlclient, and I don't want to maintain binary linking OpenSSL. Regards, -- Inada Naoki <[email protected]> _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/3A4ZTNOSMJIDAMCVTIGRMIN6LXLTWOGV/ Code of Conduct: http://python.org/psf/codeofconduct/
