
On 9 May 2016 at 23:38, Donald Stufft <donald@stufft.io> wrote:
On May 9, 2016, at 9:28 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Looking at my previous ideas for semantic dependencies in PEP 426, what if we start in the near term by defining development requirements?
I think the biggest reason not to do this, but instead do something like build requirements is that development dependencies is already reasonably well addressed in a way that something other than setuptools can access it using extras. It's not as great as a dedicated key for it, but it works pretty OK. The thing that is really painful is setup_requires and how it forces you to delay importing until *during* the execution of the setup() function. We could try and lump setup_requires and development dependencies together, but that seems less than optimal to me. Unless someone's setup.py uses pytest, I'm not sure I see a reason for pytest to be installed anytime pip builds that project.
A more concrete example would be pyca/cryptography, which has a development dependency that consists of 27MB of data which was purposely kept separate from cryptography itself so as not to incur an additional 27MB of download just to install cryptography.
OK, that makes sense to me as a rationale for prioritising build dependencies over more general dev environment dependencies. To feel confident we haven't overlooked a near term need by doing that, I think the main question I'd like to see the PEP explicitly cover is "when will these new requirements be implicitly installed?" I currently believe the answers to that are: 1. When pip* is asked to install from an sdist 2. When pip* is asked to install from a VCS URL 3. When pip* is asked to install from a local directory 4. When pip* is asked to create a wheel file for any of those * - or another compatible installer If those answers are correct, then the metadata consumer will always be proceeding on to do a build in the use cases we currently care about, so it's OK that it may also be relying on those build requirements to generate metadata or create an sdist archive. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia