commented options in inifiles

[Tim Lauridsen]

In some ini style files, like the attached fedora.repo file
some options (#baseurl=....) is commented out, if i use iniparse to add
a baseurl option, it will be added at the end of the section, because is
new option.
It would be nice if there was a way to comment/uncomment there kind of
options.

#baseurl=xxxxx -> baseurl=yyyy

baseurl=zzzz -> #baseurl=zzzz

And the order will be kept in the file.
The easiest way to implement this is to treat #baseurl=xxxx, as an
options with the name '#baseurl" and the value 'xxxx'
and the add a method to rename an option ini.rename('#baseurl','baseurl').

Tim

[Paramjit Oberoi]

I can see how this can be useful in some situations...

But I'm not sure about rename() - how about comment() and uncomment()
functions instead?

Also, what if the option was specified multiple times? Should
comment() comment out all of them? Or only the last one? If only the
last one is commented out, does the previous one become the active
value?

Uncomment should only uncomment one line, I think - the last one.
Should it be an error if multiple lines match?

Implementation wise, there are two choices. One, as you suggest, is
to modify the parsing to detect all lines that are comments but could
have been valid options. Alternatively, when comment() or uncomment()
is called, the comments could be re-parsed to identify the line to be
replaced.

Finally, what about this:

[foo]
bar=3
x=7

# [baz]
# y=9

A simple implementation of .uncomment('foo', 'y') will uncomment the
'y' in the commented out 'baz' section...

-param

> [fedora]
> name=Fedora $releasever - $basearch
> #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
> mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch
> enabled=1
> gpgcheck=1
> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY
>
> [fedora-debuginfo]
> name=Fedora $releasever - $basearch - Debug
> #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/
> mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-debug-$releasever&arch=$basearch
> enabled=0
> gpgcheck=1
> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY
>
> [fedora-source]
> name=Fedora $releasever - Source
> #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/
> mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-source-$releasever&arch=$basearch
> enabled=0
> gpgcheck=1
> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY
>
>

[Tim Lauridsen]

Paramjit Oberoi wrote:
> I can see how this can be useful in some situations...
>
> But I'm not sure about rename() - how about comment() and uncomment()
> functions instead?

Sounds fine

>
> Also, what if the option was specified multiple times? Should
> comment() comment out all of them? Or only the last one? If only the
> last one is commented out, does the previous one become the active
> value?

comment() should comment all options out in the same section

>
> Uncomment should only uncomment one line, I think - the last one.
> Should it be an error if multiple lines match?

uncomment() should only the first one in a section and return the number
of remaining hit, it make it possible to
call uncomment() again until all are uncommented, if that is what the
user want.

>
> Implementation wise, there are two choices. One, as you suggest, is
> to modify the parsing to detect all lines that are comments but could
> have been valid options. Alternatively, when comment() or uncomment()
> is called, the comments could be re-parsed to identify the line to be
> replaced.
>
> Finally, what about this:
>
> [foo]
> bar=3
> x=7
>
> # [baz]
> # y=9
>
> A simple implementation of .uncomment('foo', 'y') will uncomment the
> 'y' in the commented out 'baz' section...
>

This sounds great.

Tim

[Paramjit Oberoi]

I haven't had time to implement this... have been busy at work. It
may be a few weeks before I can get to it, so feel free to jump in...

It shouldn't be too difficult. For commenting, it's simply a matter
of iterating over iniobj._sections[sec]._lines and replacing the ones
with the given key (and removing the key from the _options dict).
There is even a make_comment function that will do the commenting.
Uncommenting is a bit more complicated - you need to iterate over the
comments and try to parse the line as an option.

As I was thinking about this, I realized that although INIConfig
objects preserve comments, etc., they only provide read/write access
to values. Maybe it's worth thinking about creating an API to access
other details of the config file?

-param

[Tim Lauridsen]

Paramjit Oberoi wrote:
> I haven't had time to implement this... have been busy at work. It
> may be a few weeks before I can get to it, so feel free to jump in...
>

There is no hurry, it is just nice to have features.
Maybe the should be a TODO list on the Wiki.

> It shouldn't be too difficult. For commenting, it's simply a matter
> of iterating over iniobj._sections[sec]._lines and replacing the ones
> with the given key (and removing the key from the _options dict).
> There is even a make_comment function that will do the commenting.
> Uncommenting is a bit more complicated - you need to iterate over the
> comments and try to parse the line as an option.
>
> As I was thinking about this, I realized that although INIConfig
> objects preserve comments, etc., they only provide read/write access
> to values. Maybe it's worth thinking about creating an API to access
> other details of the config file?
>

It would be very nice if there was an API to read/write other stuff in
the config file.
Here is some ideas.
* comment/uncomment (we have discussed this one)
* Add new comments before/in option line.
* remove comment in/before option line
* rename section.

Tim