98b63639e9
Previously, users of setuptools would get our data embedded in eggs. Eggs are horrible things, but more importantly our package data should be free, in a well-known albeit system-dependant path that is independent of the package. By specifying [install_data][1] as an alias of install, we assure that our data (examples, integrations, etc) are placed in $data/share as $DEITY intended. Alternative suggestions included force-adding "--old-and-unmanageable", which would invoke the distutils-style install command, but that had the unfortunate side effect of turning off eggs and dependency resolution altogether. We could also use "--single-version-externally-managed", but I think that was designed to be used by package managers, not by us. In any case, both of the above were fragile and might break if the user specified additional options to setup.py. In closing, Python module management is horrible. See [this][2], [this][3], and [this][4] for info about the status quo, and [this][5] for information about crack to be smoked later down the road. Don't even get me started about [PEP 427 -- Python wheels][6]. [1]: http://docs.python.org/2/distutils/commandref.html#install-data [2]: http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/ [3]: http://stackoverflow.com/a/6522905/90777 [4]: http://python-notes.boredomandlaziness.org/en/latest/pep_ideas/core_packaging_api.html [5]: https://python-packaging-user-guide.readthedocs.org/en/latest/future.html [6]: http://www.python.org/dev/peps/pep-0427/ (imported from commit 6cf1bd2b8f5a60b2f02f5d11094e4a41cc5e48aa)
4 lines
100 B
INI
4 lines
100 B
INI
# This way our scripts are installed in the data directory
|
|
[aliases]
|
|
install = install_data install
|