[SDKs] Fix Python package versions so they can be uploaded to pypi
5175: Avoid egg_info name conflicts with pip.
pip does its own subclassing of egg_info. Installing with pip fails
if setup.py includes an egg_info class that is passed in as the
cmdclass for the egg_info command. Avoid using that name to avoid
conflicts with pip. Refs #5175.
Revert 11339c91. Don't use virtualenv to build packages.
fpm and virtualenv don't play nicely together. Under virtualenv, fpm
ends up building Python packages that include the files under their
virtualenv paths. This is not what we want. Refs #5175.
#1 Updated by Brett Smith over 5 years ago
(12:14:23 PM) Me: tomclegg: As far as I can see, we should give up completely on ever trying to include the git commit hash in the version string.
(12:14:47 PM) Me: The local version identifier is the only part of the version string that would allow it under PEP 440, but we can't meet the other rules.
(12:14:55 PM) Me: Namely, "Local version identifiers SHOULD NOT be used for upstream projects."
(12:15:02 PM) Me: And, "As the Python Package Index is intended solely for indexing and hosting upstream projects, it MUST NOT allow the use of local version identifiers."
(12:16:03 PM) tomclegg: brett: possibly. It occurred to me that "local version" tags might be appropriate for packages built during development -- they shouldn't be confused with real packages that are published to pypi, etc...
(12:16:41 PM) Me: tomclegg: PEP 440 makes clear that it's meant to tag patched builds of an original version, e.g., in a distribution.
(12:17:20 PM) Me: If we want to mark our own development versions, we should use .devN. But N can only be an integer.
(12:19:21 PM) tomclegg: brett: Sure. Having an opinion about what to do with Python version numbers is a losing battle. PEP-440 has spoken.
Pushed to the branch to reflect this philosophy. Now at f32690a.