>> OK, we don't generate anything like that for Windows at the moment, >> then (where ABI is always "none"). > > "none" means "this wheel has no dependency on the ABI at all". If a > wheel includes C extensions and also has the ABI tag set to none, the > tool creating those wheels is broken (although it shouldn't be too > harmful in practice if it's also declaring an implementation specific > Python dependency, for the reasons already discussed in this thread).
I don't entirely disagree. However, that does mean that at the moment, all existing wheel tools are broken on Windows, as "none" is the only ABI flag used on Windows. For practical purposes, they do work though... :-) PEP 425 is pretty vague on the contents of the ABI field, and tools (wheel and distlib) don't offer much help for a Windows user - they pick up config variable "SOABI" (which is not defined on Windows) and they then add the items in imp.get_suffixes() that start with .abi (again, none on Windows). So, maybe we should be more specific in the PEP. Some questions, that as a Windows-based writer of wheel tools, I don't know the answers to: 1. What are the valid abi values (at least for CPython)? It appears that the answer should be 'cpXY' (with suffixes such as 'm' and 'd' - can someone clarify which and what they mean?) plus 'abi3'. PEP 384 (the stable ABI) talks about new functions being added to the stable ABI, but offers no suggestion on how or if new versions would be specified in that case. Also, shouldn't the stable ABI also have debug and similar variations? This should definitely be stated explicitly in the PEP, IMO. 2. How should tools determine which ABIs a given Python supports? (This is the get_supported function in wheel and distlib). The "Use" section of the PEP (http://www.python.org/dev/peps/pep-0425/#id1) gives a Linux-based example, but nothing normative and nothing that is understandable to a Windows user. 3. Can we reasonably assume that all existing binary distributions (wininst and/or egg) use the 'cpXY' (no stable ABI, no debug, etc) ABI? (I think the answer is probably yes, although the "use" section mentioned above implies that "cp33m" is actually right - what's the "m"?). 4. Can we reasonably assume that all existing build toolchains (distutils and setuptools are the key ones) will generate the 'cpXY' ABI? (Again, I think the answer is yes). There's also the big overriding question, which is do we really need to worry right now? Personally, I feel that the current state of affairs ("none" as the ABI for Windows, and no real support for things like debug builds or the stable ABI) is useful as it stands, and we shouldn't let a quest for perfection block what is already a useful practical tool. (On the other hand, the "none on Windows" issue could give us a migration issue to deal with when we finally fix it, if we leave it as it is for now). Paul _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
