Open Stack

Excerpts from Jesse Pretorius's message of 2017-10-03 09:02:19 +0000:
> On 10/2/17, 1:45 PM, "Doug Hellmann" <doug at 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