Open Stack

On 07/02/2015 05:51 AM, Robert Collins wrote:
> On 2 July 2015 at 13:26, Thomas Goirand <zigo at debian.org> wrote:
>> On 07/02/2015 02:07 AM, Tony Breeds wrote:
>>> On Wed, Jul 01, 2015 at 11:07:30PM +0000, Perry, Sean wrote:
>>>> BTW, see dh_bash-completion from the debhelper package. When in doubt about packaging on a deb based distro look at the debhelper tools source (which is perl).
>>>>
>>>> -----Original Message-----
>>>> From: Perry, Sean
>>>> Sent: Wednesday, July 01, 2015 4:04 PM
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a package
>>>>
>>>> According to Debian standards (which Ubuntu follows mostly) if a package
>>>> ships bash completion information that file belongs in /etc/bash_completion.d
>>>> with a file named after the package. You can look in that dir on an
>>>> Ubuntu/debian box and see the setup.
>>>
>>> Right, but I'm talking about python packaging.  Which is certainly closely
>>> related to system/distribution packaging, but lacks a lot of the machinery
>>> to get it right.
>>
>> Correct. Python packaging is made for packaging ... python! Not
>> configuration files and other system bits.
> 
> I'm with you there. BUT. Python programs use configuration files. And
> Python programs provide daemons. Its entirely reasonable and expected
> within the context of a given program that 'sudo make install' or
> 'sudo setup.py install' or <...> any number of variations should make
> the program be usable by all users of the system that its installing
> it into.
> 
> I'm going to presume we agree on that in the rest my reply. You may
> want to stop here if we don't agree about that.

We do agree. The issue being that there's no universal way to do things,
and different policy depending on the unix vendor and the way package is
designed.

>>> What I'm trying to do is:
>>> 1) make it simple for the 'developer' comsumers of the python package to use
>>>    bash completions (witghout needing the system packages)
>>
>> Use the source, luke! Or write yourself a small shell script...
> 
> Unless-and-until distributions provide a standard home-dir scoped
> place to install bash completion scripts, developers and users
> installing from python packaging are going to expect that the
> completion scripts in the software they are installing get installed.
> Expecting every user to home-roll a workaround multiplies the overall
> cost by the number of users. So I can imagine three routes...
>  - teach the thing being installed to install completion scripts into
> the existing right place(s)
>  - define a new place thats homedir and virtualenv friendly and teach
> the thing installing them to install there.
>  - punt and do nothing

There's a 4th way: add some kind of parameters to (not) do the
installation of config files. I'd say: have it not install config files
by default, and add an option to setup.py install to do it. This way,
everyone is happy.

> There's a big chunk of complexity hidden in my second point there. And
> even if we do it we still need to get it onto our dev machines: Mac OS
> X, various versions of Ubuntu, Fedora, RHEL and Suse. So I don't think
> it makes a lot of sense to bank on getting that right-and-out-there
> before we look at the user experience directly.

Yup.

>>> 2) Help the system/distribution packagers or at the very least not make thier
>>>    life more difficult.
>>
>> If you attempt to address this, you're making my life miserable. Please
>> don't do it, thanks.
> 
> Since the entire job of the dh-* script ecosystem is to automate
> repeated patterns without making individual developers figure things
> out, I find 'miserable' comes across as a massive exaggeration.

Let's say every bits of the software we release was doing things wrong,
because of wrong assumptions by the upstream maintainers who aren't
familiar with the "Debian Policy Manual", or with packaging automation
principles (you mentioned debhelper, but there's also OpenStack specific
tooling which I wrote), then there's a high chance that "python setup.py
install" would do the wrong things with configuration files (or at
least, not what *I* want it to do). Repeat this by the number of
packages I maintain, and then having a miserable life unwinding the
cruft is effectively miserable.

> Surely
> its a single one-off dh script to create to handle bash completion
> scripts and move them into the right place, and you are done?

The fact that I would like to use the dh script is exactly the reason
why I don't want upstream to get in involved. If upstream maintainers
does nothing, then I just write:

echo "tools/nova.bash_completion nova" \
	>debian/python-novaclient.bash-completion

This way, I leave up to dh_bash-completion to decide where to install
the bash completion script. Using this way, I am sure that my package is
always Debian policy compliant, even if the Debian policy evolves (and
it did for completion scripts, moving from /etc to /usr recently).

If upstream maintainers pretend that they know how to do things, then I
have to do what's above, plus, in my debian/rules file:

override_dh_auto_install:
  rm $(CURDIR)/debian/tmp/etc/bash_completion.d/nova.bash-completion
  dh_auto_install

to remove what setup.cfg pretends to know, and make sure my package
stays Debian policy compliant.

So of course, I would very much prefer to have to do only the former,
and not having upstream author impose to me doing the former on top.

Cheers,

Thomas Goirand (zigo)