[Distutils] C extension dependencies

[Donald Stufft]

> On Sep 11, 2014, at 8:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 11 September 2014 18:48, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
>> 
>> On Sep 11, 2014, at 4:37 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> 
>> On 11 September 2014 08:15, Donald Stufft <donald at stufft.io> wrote:
>> 
>> Perhaps the gains wouldn’t be worth the complexity though and it’d
>> just be easier to allow projects to have a build hint thing that gets
>> printed if the build fails.
>> 
>> 
>> Putting it in core pip sounds to me like a recipe for endless
>> system-specific hacks, TBH. Having a plugin system that allowed
>> external packages to add (and maintain!) system-specific checks might
>> work, but that's pretty complex.
>> 
>> Paul
>> 
>> 
>> Yes to be specific the only thing I would personally be OK with adding to
>> the
>> pip core is something that added the appropiate hooks to let some other
>> thing
>> provide the platform specific mechanisms. I'm still not sure it's worth the
>> effort over the simpler idea of just providing a build_hint metadata that
>> authors can use to say "Hey you need to isntall libxml2 for this thing" or
>> whatever.
> 
> It actually occurs to me that the GNU autoconf directory scheme may be
> useful here - if people define their dependencies in terms of that
> scheme, it should be possible for a plugin to figure out how to ask
> the OS installer for them, or otherwise check for them in a virtualenv
> or conda environment.
> 
> And, if no such plugin is available, the fallback option would be to
> just tell the user what's missing.
> 
> (FWIW, the only major barrier I see to formalising the metadata 2.0
> spec at this point is the lack of up to date jsonschema files. Getting
> that out the door may be something to explore post pip 1.6)
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia


I’d like to take a close look at Metadata 2.0 and see about doing some
proof of concept implementations before we actually accept that PEP.
Basically the same thing I did for PEP 440. I think the feedback from
actually attempting to use it was invaluable.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140911/3853f9ca/attachment-0001.html>