Added a buildout option, abi-tag-eggs

[jimfulton]

that, when true, causes the ABI tag <https://www.python.org/dev/peps/pep-0425/#abi-tag>_ for the buildout
environment to be added to the eggs directory name.

This is useful when switching Python implementations (e.g. CPython
vs PyPI or debug builds vs regular builds), especially when
environment differences aren't reflected in egg names. It also has
the side benefit of making eggs directories smaller, because eggs
for different Python versions are in different directories.

[jimfulton]

paweeze, someone review this.

This is very useful when working on projects that support both PyPy and CPython.

[jamadden]

Seems pretty straightforward and simple enough.

I had one feature request. I didn't give much thought to it though, so it may not be possible.

[jamadden]

FWIW, if possible I would prefer to have the api-specific eggs-directory beneath the egg directory I specify (or is default). This prevents cluttering of the top-level directory. It also means that a bunch of .gitignore files won't have to be updated to ignore a bunch of new 'eggs-pypy', etc, directories.

In my case, I have one main eggs-directory set in ~/.buildout/default.cfg. I have a different backup policy set for that directory. Some people may place that directory on larger (slower) storage. That directory may also have different permissions than its containing directory. It would be nice not to have to make those changes for more directories (whose name you can only guess at until they're created).

[jimfulton]

Of course possible, and good point wrt .gitignore. I'll update the PR.

[leorochael]

Hi @jimfulton, nice feature!

@jamadden wrote:

FWIW, if possible I would prefer to have the api-specific eggs-directory beneath the egg directory I specify (or is default). [...]

I second that, for all the given reasons.

Even better would be if the abi-independent eggs remained in the root buildout:eggs-directory to save space. The space saving of sharing eggs between multiple buildouts (when configured at the user home) and buildout parts (at the very least) is one of the best features of buildout that is still missing from virtualenv based solutions.

But I guess this would require a much bigger PR, and we could have problems of incompatibility with the generated .pyc files in Python < 3.2 (would there be any such problem in reality?)

[jamadden]

Yeah, the ideal solution would be if the eggs themselves included the ABI in the same way that wheels do. But I don't know what it would take to accomplish that. This is here and it works 😄

[jimfulton]

This is a bit of a stop gap until we move to a standard venv recipe of some sort. (Assuming that we do. :-))

So I'm inclined to stick with this simple PR (with Jason's suggestion).

This issue illustrates why adding wheel support to eggs isn't much of a solution, at least unless the abi information was included in egg names and was used correctly. Not that that should be soooo hard, but not something I'm willing to volunteer for any time soon.

[jimfulton]

BTW, The abi tag captures the Python version, so there aren't abi-dependent eggs. :)

There is a potential savings for platform-independent eggs in cases where there's more than one abi variant for a platform but I don't think that will be the case for most people. (It will be for me, but I can cope.)

[jamadden]

Ahh, I guess I was combining what the wheel spec refers to as the "python tag" with the "abi tag". A foo-1.0-py2.py3-none-any.whl wheel has an ABI tag of "none" and a python tag of "py2.py3".

[jimfulton]

Released as 2.7.0