Excerpts from Jesse Pretorius's message of 2017-10-03 09:02:19 +0000: > On 10/2/17, 1:45 PM, "Doug Hellmann" <d...@doughellmann.com> wrote: > > > etc implies they should be edited, though, and we're trying to move away > > from that at least for the paste.ini files in most projects. So we may > > need to decide on a case-by-case basis, unless we declare all of these > > files as "sample" files that should be copied into the right place > > before being edited. > > For ‘sample’ files, where would be an appropriate placement? The relative > path ‘share’ instead of ‘etc’? > > The placement of the files really should be focused more on the problem it’s > trying to solve. > > The use-cases exposed so far are: > > 1. For OpenStack-Ansible or any other deployment project deploying from > source, the only problem we’d like to have any configuration files for > services included in a compiled wheel. The path is irrelevant to us as we can > move the files to where they need to be, but we would like to cut out a bunch > of code which we now use to fetch these files from the git source, or > alternatively the vendored copies of the files we carry. > 2. Packagers I’ve had discussion with also have implementations which fetch > these files from the git source. For them the sentiment appears to be largely > the same – consistency of placement for the files is important. > 3. For anyone installing the software via a compiled wheel for whatever > reason, things get a little muddy – some want the files in the default > locations that the software looks for it so that after installation ‘it just > works’. > 4. Some packagers want the files to be placed in the system root path > appropriate for the file when it is installed via a package. > > To me the third use-case is a nice-to-have, given that if the files are > consistently placed then it can be worked with and anyone doing that already > has something to cover that need. > > To me the fourth use-case is out of scope. It needs resolving via setuptools > and/or pep 491 before that can move forward.
I think I agree with all of that analysis. My gut says put the files in "share" but maybe the folks more familiar with package layout have better insight. > > Given that this topic has gone through several cycles of discussion and has > never gone anywhere, does it perhaps merit definition as a project interface > so that we can define the problem this is trying to solve and set a standard > formally once and for all? > Maybe a couple of the various packaging projects can agree and just set a de facto rule (and document it). That worked out OK for us with the doc reorganization when we updated the docs.o.o site templates. Doug __________________________________________________________________________ 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
