On 2017-10-12 09:06:28 +0000 (+0000), Jesse Pretorius wrote: > On 10/12/17, 8:55 AM, "Thomas Goirand" <z...@debian.org> wrote: [...] > > Also, in the packaging process, there's a few tweaks that are > > necessary for the distro integration. A quick example: in the > > nova package, I've set sensible default for [DEFAULT]/pybasedir, > > [DEFAULT]/bindir, [DEFAULT]/state_path. Even if you were > > shipping a nova.conf in the correct location, the Debian package > > would have to fix these directives. I've seen that Ubuntu does > > something similar also. > > ‘Sensible defaults’ are subjective to the use-case. As mentioned > above, we will be modifying the files and I expect that all > distributions/deployments have adjustments to better suit their > use-cases. In this particular case you’re mentioning .conf files > which are supposed to be generated, not included. > > > I still didn't have any reply on my PBR change proposal. Your > > thoughts? > > Your proposal is likely going to end up requiring multiple env > vars because data_files could be marked for any location – unless > you’re wanting some sort of env var for each top level file > destination? In that case it’s going to get messy fast. It sounds > like it’d be better to try and implement another file type in > distutils/setuptools which is recognized as different. Perhaps > something like ‘config_files’ which could then have its own CLI > option to place them differently to ‘data_files’.
I highly encourage people with an interest in properly solving this to please, please, please... 1. get involved on the distutils-sig ML 2. at least skim this thread, and if it makes sense then resurrect it and pitch in on drafting a proper PEP (building on top of the changes coming in PEP 517/518 at this stage would likely make the most sense): https://mail.python.org/pipermail/distutils-sig/2015-April/026222.html Any "fix" for this in PBR is only going to be an ugly hack workaround which drives the wedge between us and the greater Python ecosystem ever deeper. They already get the impression we make up our own self-serving solutions instead of helping out, so let's try not to make that situation even worse if we can help it. -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ 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
