Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate and remove 'Features' #65

Closed
ghost opened this issue Aug 11, 2013 · 16 comments
Closed

Deprecate and remove 'Features' #65

ghost opened this issue Aug 11, 2013 · 16 comments
Labels

Comments

@ghost
Copy link

@ghost ghost commented Aug 11, 2013

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.


@ghost
Copy link
Author

@ghost ghost commented Aug 11, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


In 741d1f64ba40, I've officially deprecated the Features functionality with the intention of removing it in a future release.

@ghost
Copy link
Author

@ghost ghost commented Aug 15, 2013

Original comment by Merwok (Bitbucket: Merwok, GitHub: Merwok):


The warnings.warn call should use the stacklevel argument to let Python display the right calling source file.

@ghost
Copy link
Author

@ghost ghost commented Aug 15, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Excellent idea.

@ghost
Copy link
Author

@ghost ghost commented Aug 16, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I set the stacklevel to 3 in 6a7c54c2c48f. I believe that's the most useful stacklevel (although it's difficult to know exactly what stacklevel will be appropriate).

@ghost
Copy link
Author

@ghost ghost commented Aug 16, 2013

Original comment by Merwok (Bitbucket: Merwok, GitHub: Merwok):


It’s easy to test: use Feature in a setup.py script, run it, see that the warning shows the line from setup.py, not setuptools.

@ghost
Copy link
Author

@ghost ghost commented Feb 9, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Removed Features functionality. Fixes #65.

@ghost
Copy link
Author

@ghost ghost commented Mar 6, 2014

Original comment by mitsuhiko (Bitbucket: mitsuhiko, GitHub: mitsuhiko):


Just as a general hint, the following packages are broken through this change:

  • SQLAlchemy (it now thinks setuptools is unavailable and installs through distutils)
  • MarkupSafe
  • PyProtocols
  • cffi
  • pymongo

And that's just packages I found on a quick github code search.

Why was this change done?

@ghost
Copy link
Author

@ghost ghost commented Mar 6, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


The very first link in this ticket to #58 explains the rationale.

@ghost
Copy link
Author

@ghost ghost commented Mar 6, 2014

Original comment by haypo (Bitbucket: haypo, GitHub: haypo):


Related issue in OpenStack:
https://review.openstack.org/#/c/78701/

@ghost
Copy link
Author

@ghost ghost commented Mar 8, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


7306814c7297 re-opens this issue.

@ghost
Copy link
Author

@ghost ghost commented Mar 8, 2014

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.

@ghost
Copy link
Author

@ghost ghost commented Apr 7, 2014

Original comment by aratto (Bitbucket: aratto, GitHub: aratto):


The link printed out by the warning is broken (missing '/issue/' in path).

Just to provide a new usage example: I am using features to opt-in and install testing dependencies. (setup.py --with-testing develop)

@ghost
Copy link
Author

@ghost ghost commented Aug 25, 2014

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!
Thanks!

@ghost
Copy link
Author

@ghost ghost commented Jul 24, 2015

@ghost ghost added major bug labels Mar 29, 2016
lpsinger added a commit to lpsinger/gwcelery that referenced this issue Dec 19, 2018
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']),
oschwald added a commit to maxmind/MaxMind-DB-Reader-python that referenced this issue Sep 24, 2019
@jaraco
Copy link
Member

@jaraco jaraco commented Jan 19, 2020

Quickly reviewing the aforementioned projects:

  • SQLAlchemy dropped the dependency on this feature in 2015
  • Markupsafe no longer uses the feature.
  • Pyprotocols still uses it but only because it hasn't changed since 2014.
  • cffi is no longer using the feature (though I can't tell where it stopped)
  • Pymongo dropped it in 2014.

Given the deprecation warning has been loud and obnoxious for half a decade, it's time to remove the functionality.

jaraco added a commit that referenced this issue Jan 19, 2020
This commit reverts e4460fa.
@jaraco
Copy link
Member

@jaraco jaraco commented Jan 19, 2020

It looks like zope.interface referenced above still relies on this feature. I'm going to ping that ticket and let them know about the impending breakage.

@jaraco jaraco closed this in #1979 Mar 8, 2020
@megies megies mentioned this issue Mar 9, 2020
1 of 9 tasks complete
fmigneault added a commit to Ouranosinc/Magpie that referenced this issue Mar 9, 2020
…interface#30) to fix missing 'Features' feature officially removed (via pypa/setuptools#65) and pin setuptools<46.0.0
userkkw added a commit to userkkw/openslide-python that referenced this issue Mar 21, 2020
sigmavirus24 added a commit to heroku/pghstore that referenced this issue Apr 1, 2020
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
PiRK added a commit to PiRK/openslide that referenced this issue Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

1 participant