Open Stack

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.

>> 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 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.

>> 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. 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?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud