Deprecate and remove 'Features' #65
Comments
|
Original comment by mitsuhiko (Bitbucket: mitsuhiko, GitHub: mitsuhiko): Just as a general hint, the following packages are broken through this change:
And that's just packages I found on a quick github code search. Why was this change done? |
|
Original comment by haypo (Bitbucket: haypo, GitHub: haypo): Related issue in OpenStack: |
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): In the discussion following the unsuccessful release of 3.0, some use-cases of features were discovered that may not be obviated by use of extras. Namely, extras are always opt-in while features enabled opt-in and opt-out. Consider SQLAlchemy, which exposes a Feature for it's C-extension speedups. The default build process includes the C-extension and then a particular user or environment can opt-opt with --without-cextension. The recommended way to use extras for this purpose would be to create a separate package for the c extension, then reference that additional package as an 'extra'. This mechanism, however, would require that users of SQLAlchemy would need to update their requirements to include SQLAlchemy[cext] to retain the default behavior. There's no way SQLAlchemy to declare that 'cext' is a preferred inclusion or for a user to exclude the dependency explicitly. On the other hand, having the speedups defined in a separate package gives installer, deployment, and packaging tools more control over which features are present. A tool can quickly assess the presence (or absence) of speedups if they're defined in a separate package. I think the benefits of using extras outweigh the loss of control with opt-out Features, but I'll explore this concept with the SQLAlchemy project. Interestingly, every example of the use of Features has been for the inclusion or exclusion of compiled C extensions. Perhaps that's an indication of a different need relating to compiled extensions. |
|
Original comment by marscher (Bitbucket: marscher, GitHub: marscher): I'am one of the maintainers of Jpype1 and want to distribute a new "Feature", which depends on the presence of Numpy. I need to define a macro and set numpy as additional include_dir for extension building. Currently the setup script checks, if Numpy is importable and sets those things. But by doing so, it's not possible to disable the feature. So I've tried to define it via extras_require, but then I have no clue how to determine, if setup is being called with "[numpy]" extra or not and change the Distribution class accordingly. I would really appreciate any hint of solving this problem! |
|
Original comment by zzzeek (Bitbucket: zzzeek, GitHub: zzzeek): note: https://bitbucket.org/zzzeek/sqlalchemy/issues/3500/remove-with-out-cextensions-from-installer |
ghost
added
The Sentry intersphinx file causes warnings like this:
/tmp/easy_install-uspc1p4m/MarkupSafe-1.0/setup.py:20: DeprecationWarning: Flags not at the start of the expression '^__version__\\s+=\\s+(' (truncated)
'^__version__\s+=\s+(.*?)$(?sm)', f.read()).group(1))
/tmp/easy_install-uspc1p4m/MarkupSafe-1.0/setup.py:27: DeprecationWarning: Features are deprecated and will be removed in a future version. See pypa/setuptools#65.
Extension('markupsafe._speedups', ['markupsafe/_speedups.c']),
|
Quickly reviewing the aforementioned projects:
Given the deprecation warning has been loud and obnoxious for half a decade, it's time to remove the functionality. |
|
It looks like |
…interface#30) to fix missing 'Features' feature officially removed (via pypa/setuptools#65) and pin setuptools<46.0.0
In setuptools 46.0.0, the project dropped support for "features" and instead we should be using ext_modules. This updates the project to build on setuptools 46.0 and newer. Refs pypa/setuptools#65
CCompiler.has_function: Do not fail if self.outputdir is set
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
In #58, it comes to my attention that the Features implementation is incomplete and should be removed.
The text was updated successfully, but these errors were encountered: