On Fri, Mar 21, 2014 at 10:25 AM, Paul Moore
On 21 March 2014 13:46, Daniel Holth
wrote: It mostly has to implement egg_info and install to be pip compatible.
At a *very* brief scan, pip uses just the following setup.py invocations (this definitely needs to be properly audited before relying on it):
For installation from sdist * setup.py egg_info [--egg-base XXX] * setup.py install --record XXX [--single-version-externally-managed] [--root XXX] [--compile|--no-compile] [--install-headers XXX]
For editable installs * setup.py develop --no-deps
Not sure, used in RequirementSet * setup.py clean
For pip wheel * setup.py bdist_wheel -d XXX
Note that installation from wheel requires *no* setup.py interface. Nearly all of this is for installation from sdist (which long-term is expected to be deprecated - install via wheels is the intended "way of the future", and PR #1572 is the first step on the way to that). While theoretically you can build wheels any way you like, I expect "pip wheel XXX" to be the canonical approach (it's how PR#1572 works) and at the moment that means implementing setup.py bdist_wheel.
So, at a bare minimum, you could get away with just supporting setup.py bdist_wheel (and not supporting editable installs or installs direct from source). It might need PR #1572 to make this palatable, of course.
You do need to keep a mechanism to indicate & install build dependencies.
Also, there's the fact (which I glossed over) that pip currently doesn't run setup.py directly, but does some nasty hackery to inject setuptools. Before working on standard build interfaces, we probably need to refactor that out somehow. Maybe a simple flag (that could be set in setup.cfg) that says "use setup.py without monkeypatching" would be enough...
Paul