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. 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? ________________________________ Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __________________________________________________________________________ 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
