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

[MRG+1] Add optional external dependencies to extras_require #1345

Open
wants to merge 1 commit into
base: master
from

Conversation

@barraponto
Copy link
Contributor

@barraponto barraponto commented Jul 7, 2015

Having the external dependencies in extras_require would be useful to raise
awareness of our optional features, let projects that depend on those features
declare it in the proper syntax (like scrapy[JMESpath]) and have us thinking
twice before adding more of those.

@nramirezuy nramirezuy changed the title Add optional external dependencies to extras_require [MRG+1] Add optional external dependencies to extras_require Jul 13, 2015
@kmike
Copy link
Member

@kmike kmike commented Jul 29, 2015

I'm not sure if we need this kind granularity.
For example, if we will ever want to remove JMESPath for some reason, we'll have to keep 'JMESPath' in extras_require because if users have scrapy[JMESPath] in their requirements.txt installation will start to fail. I think it is better to name extra requirements after Scrapy features which are enabled by them, like you've done with scrapy[s3]. E.g. scrapy[shell] can install IPython, etc.

Another option is to just add scrapy[full] extra requirement which will install all optional dependencies.

@barraponto
Copy link
Contributor Author

@barraponto barraponto commented Jul 30, 2015

@kmike if we no longer need the jmespath package to support jmespath, then we can declare an empty set of requirements. if we drop the jmespath feature at all, then it's up to the package depending on it to update its dependencies.

@kmike
Copy link
Member

@kmike kmike commented Jul 30, 2015

@barraponto you're right there are ways to deal with it. But what's an advantage of writing pip install scrapy[jmespath] instead of pip install scrapy jmespath?

@barraponto
Copy link
Contributor Author

@barraponto barraponto commented Jul 31, 2015

That is just because jmespath is both a feature name and a package name. But should the dependencies for that feature change (adding or removing packages), projects depending on scrapy[jmespath] should still work.

@nramirezuy
Copy link
Contributor

@nramirezuy nramirezuy commented Aug 20, 2015

@kmike We have control over the version installed :)

@Gallaecio
Copy link
Member

@Gallaecio Gallaecio commented Mar 24, 2020

  • For visibility, I think covering those optional dependencies in the right parts of the documentation is enough. If we want to raise more awareness, I think a better approach would be to add a new section to the Installation page, rather than using extras_require.
  • I see no benefit in scrapy[jmespath] instead of scrapy jmespath. And lock files need to have a separate entry for jmespath anyway.
  • I think version restrictions (@nramirezuy’s point) would be a valid point. But only if we need them, and I don’t think we do at the moment.
  • On the other hand, if we ever use extras_require, I don‘t see a problem with we removing some of them later. It would fail loudly when upgrading, and the “fix” would be clear.

All in all, I propose we close this, but keep extras_require in mind in case we ever want to release a new version of Scrapy that does not support the latest version of its optional dependencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.