Open Stack

On 2017-09-29 18:39:18 +0200 (+0200), Thomas Bechtold wrote:
> On 29.09.2017 12:56, Jesse Pretorius wrote:
> > On 9/29/17, 7:18 AM, "Thomas Bechtold" <tbechtold at suse.com> wrote:
> >
> >     This will still install the files into usr/etc :
> >     It's not nice but packagers can workaround that.
> >
> > Yes, that is true. Is there a ‘better’ location to have them? I
> > noticed that Sahara was placing the files into share, resulting
> > in them being installed into /usr/share – is that better?
> 
> There is /etc [1]
[...]

Not really, no, because the system-context data_files path has to be
relative to /usr or /usr/local unless we want to have modules going
into /lib and entrypoints in /bin now. There was a somewhat thorough
discussion on the distutils-sig ML a couple years ago (I think? my
sense of time is pretty terrible) of a potential solution involving
setting up a taxonomy of data file types and allowing
installers/package maintainers to map those to whatever they want
(FHS for distro packages maybe, relative to the install root for
virtualenvs, and so on). I can't seem to find that proposal now, nor
does it appear to have gotten as far as becoming a PEP, but I'll
admit I only spent a few minutes digging around for it.

The current situation with data_files behavior is complicated by the
multitude of ways and places Python packages can be installed,
resulting in bug reports like:

    https://github.com/pypa/setuptools/issues/130
    https://github.com/pypa/setuptools/issues/460
    https://github.com/pypa/setuptools/issues/807

Also there's the problem that it's just a single bucket which could
be used to house example configuration files, shared datasets,
manpages or similar documentation... so dumping all those into a
single path is pretty messy anyway.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/39471609/attachment.sig>