[Python-ideas] bdist naming scheme (compatibility tags) PEP

[Paul Moore]

On 25 September 2012 22:08, Daniel Holth <dholth at gmail.com> wrote:
> I don't think the exact order of the less-preferred options is
> critical, as long as you can make up your mind about whether you
> prefer packages with or without the C extension. Your Python is not
> likely to be compatible with competing py34 and cp32 wheels for the
> same version of a distribution. Most distributions will use either the
> cpXX style or the pyXX style tags, but not both.



>
>> On this basis, implementations should *not* declare none-any
>> combinations, as they can be automatically deduced.
>
> +0. algorithmically at least. It would not be wrong to dial down the
> "previous versions" logic quite a bit, too, as far as only doing cp33,
> cp3, py33, py3 which would mean "only use packages that are for our
> Python or explicitly cross-version".
>
>> One minor question on this, though, is the statement in the PEP "A
>> user could instruct their installer to fall back to building from an
>> sdist more or less often by configuring this list of tags". I don't
>> see what this means - it should probably be either clarified or
>> omitted.
>
> In the above "fewer old tags by default" case, if you are on Python
> 3.3 and don't install cp32 by default, you could say "also install
> cp32 for this one package that I know works" by adding the cp32 tag to
> the list. This is to be compatible with lazy human packagers.
> Similarly when you are a version behind you will sometimes need to
> install packages built for the next version of Python.
>
> Or you could remove all binary package tags of the form
> *-abi3-linux_x86_64 from the list that your installer uses to consider
> whether to download a built package or an sdist from pypi. It would
> still download built pure-Python packages.
>
>> This isn't particularly a criticism of the PEP, it's just that the
>> wording tends to obfuscate the essentials by hinting at complexities
>> that don't really exist in practice. For example, given the above, the
>> only really meaningful compressed tagset I can imagine is
>> py2.py3-none-any. Apart from this one use case, which admittedly is
>> important, the whole compressed tagset capability is unlikely to ever
>> be needed.
>
> Who knows. I imagined bundling a windows and a Linux dll in a single
> built package, or doing something with OS X fat binaries. If the
> shared library has the same __pycache__/name.tag.so style naming then
> this feature gets more interesting, if not difficult to package.
>
> It doesn't currently exist in practice.