On 2017-10-12 09:06:28 +0000 (+0000), Jesse Pretorius wrote:
On 10/12/17, 8:55 AM, "Thomas Goirand" firstname.lastname@example.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
Your proposal is likely going to end up requiring multiple env
vars because datafiles 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 ‘configfiles’ 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...
get involved on the distutils-sig ML
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
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.
OpenStack Development Mailing List (not for usage questions)