On Monday, 2 October 2017 13:28:17 CEST Thomas Goirand wrote: > On 09/28/2017 04:50 PM, Jesse Pretorius wrote: > > There’s some history around this discussion [1], but times have changed > > and the purpose of the patches I’m submitting is slightly different [2] > > as far as I can see – it’s a little more focused and less intrusive. > > > > > > > > The projects which deploy OpenStack from source or using python wheels > > currently have to either carry templates for api-paste, policy and > > rootwrap files or need to source them from git during deployment. This > > results in some rather complex mechanisms which could be radically > > simplified by simply ensuring that all the same files are included in > > the built wheel. Distribution packagers typically also have mechanisms > > in place to fetch the files from the source repo when building the > > packages – including the files through pbr’s data_files for packagers > > may or may not be beneficial, depending on how the packagers do their > > build processes. > > > > > > > > In neutron [3], glance [4], designate [5] and sahara [6] the use of the > > data_files option in the files section of setup.cfg is established and > > has been that way for some time. However, there have been issues in the > > past implementing something similar – for example in keystone there has > > been a bit of a yoyo situation where a patch was submitted, then reverted. > > > > > > > > I’ve been proposing patches [7] to try to make the implementation across > > projects consistent and projects have, for the most part, been happy to > > go ahead and merge them. However concern has been raised that we may end > > up going through another yo-yo experience and therefore I’ve been asked > > to raise this on the ML. > > > > > > > > Do any packagers or deployment projects have issues with this > > implementation? If there are any issues, what’re your suggestions to > > resolve them? > > I still have the issue that adding stuff in etc, at packaging time, push > them in /usr/etc, which is obviously wrong. We tried to push for a PBR > patch, but failed, as Robert Collins wrote it had to be fixed in > setuptools. Which is why all patches have been reverted so far. > > While I may agree with Robert, I think we had to choose for a pragmatic > (even temporary) solution, and I don't understand why it's been years > that this stays unfixed, especially when we have an easy solution. [1] > > So, until that is fixed, please do not propose this type of patches.
Why not? Even if it does not fix the issue for proper installations, - it does not provent people from copying the files somewhere else (it happened in sahara for how long I can remember, we have been using data_files) - it fixes the deployment when the package is installed in a virtualenv; - it introduces consistency: the day data_files starts to do the right thing, everything will work; if it's not possible to fix it with data_files, it's easy to spot which files should be fixed because all handled by data_files. So definitely go for it. Ciao -- Luigi __________________________________________________________________________ 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