Merge lp:~rexbron/bzr-builddeb/trunk.profiles into lp:~bzr-builddeb-hackers/bzr-builddeb/trunk-old

Adds support for profiles in bzr-builddeb. Profiles are stored groups of settings, callable from the command line. This is useful when multiple builder strings are required depending on the destination.

Hi,

Thanks for working on this, apologies for the delay in reviewing it.

The change looks small and un-obtrusive, I just have a question about
the config file format. You went for

  [revu]
  profile-builder = "foo"

I think this should be

  [revu]
  builder = "foo"

However I was expecting

  [PROFILES]
  revu = "foo"
  ppa = "bar"

etc.

Your way obviously allows us to define other things for a profile, but I am
struggling to think of what that might be. Do you have any examples?

Also, what do you think about case-sensitivity. I think the profile names should
be case-insensitive, but that is obviously not that easy to accomplish. How
important do you think that is?

Thanks,

James

Two reasons that I went with the config file format that I did, the first was namespace conflicts. I wanted to be certain, as I do not fully understand how this config system works, that I would not be interfering or causing unintentional changes. Secondly, as you mention, it might be possible in the future that we wish to add other options to a profile but I do not have any explicit examples at this point.

Making profile names case insensitive depends on how the config system works when it parses the config file. I have done some work on managing config files from python (see ubuntustudio-controls). If it uses regex to find the section header, then it would be a simple matter of modifying the regex passed to be case-insensitive. If it parse config files in a different manner, then I would need to think further, but I do agree that section headers should be case-insensitive.

Hi,

Sorry for the delay, I merged your branch with trunk and made some
tweaks:

  https://code.edge.launchpad.net/~james-w/bzr-builddeb/profiles

though I realise I forgot to change README.

I'm quite happy that the change is small. My remaining concern is
just utility vs. maintainence burden. I want to be sure that this
solves a use case well enough that it's worth the effort of maintaining
it. If you can explain what you want to use it for that will help.

Thanks,

James