Excerpts from Thomas Goirand's message of 2017-10-10 22:03:44 +0200: > On 10/10/2017 01:16 PM, Jesse Pretorius wrote: > > Regardless, given that this is not functionality currently> available for > > setuptools, distutils or pbr it would seem > > that this functionality (or another applicable workaround) > > would have to be carried by Debian packaging until such > > time that such a facility exists in the python tooling. > > We don't control setuptools/distutils directly. The only thing we > control is PBR. So my proposal is: > > 1/ Design a new config_files directive in setup.cfg and patch PBR so > that it understands it.
We are doing other work to make pbr have *fewer* features. I'm not sure this is the sort of direction we would want to go, although I'm not voting -2 right now. I still think we should just be looking at these files as sample data and not active configuration files when we put them into the sdist or wheel. Doug > > Considering the python module named foo, this could end up like this: > > [files] > config_files_dest = PYBASE/foo > config_files = foo.cfg > > then PYBASE would be expanded to /usr/lib/python2.7/dist-packages in the > case of Debian + Python 2.7. > > or, as another example: > > [files] > config_files_dest = foo > config_files = foo.cfg > > then foo.cfg would end up in /usr/share/foo/foo.cfg unless the env var > OSLO_CONFIG_FILES_DEST is set (for example to /usr/share/foo-common, or > to /etc/foo). I don't really mind whatever is decided for the > non-packaging use case (ie: pip install ?). > > 2/ Make PBR to read the destination path from something configurable at > a packaging level, that would overwrite the default behavior, so that we > could have whatever the package maintainer decides. > > 3/ When the new PBR release has the new feature, let individual packages > use the new config_files directive that would simply list the config > files with the preselected destination. > > Does this seem a good plan? Please comment on the above. > > Cheers, > > Thomas Goirand (zigo) > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev