[Freeipa-devel] Utility modules and unused code

Rob Crittenden rcritten at redhat.com
Mon Apr 16 15:08:28 UTC 2012


Petr Viktorin wrote:
> I've started looking at our test coverage and noticed that our utility
> modules have a lot of stuff that's not only untested, but also unused.
> Some of these are left over from Radius support or other ancient code.
>
> What to do with these? Remove them for 3.0, or be careful and just
> deprecate them with a warning?
> Or did I look wrong and some of them still useful?
>
>
> Seeing the util modules, I'd recommend to leave future code that *could*
> be potentially useful in more places, but currently isn't, near the
> place that uses it. It is easy to put in a common location if there's
> need for it later, but removing something once all its dependencies are
> gone is more problematic.
> Not to mention that it's hard to write generic code when there's just
> one use for it, or that such code is hard to change once something else
> might depend on it.
>
>
>
>
> Unused code I found:
>
> ipapython/ipautil.py:
> format_list
> parse_key_value_pairs
> read_pairs_file

Left overs from radius support. It can probably go, we can revive it if 
needed. I must have missed these when I removed the rest of the radius code.

> user_input_plain

This is left over from v1, it can go.

> AttributeValueCompleter
> ItemCompleter

Jason intended to add tab support to some parameters. I believe these 
are related to that effort. Not sure what it'd take to revive it.

>
> ipaserver/ipautil.py:
> get_gsserror [ipapython.ipautil.get_gsserror (!!) is similar but used]

The one in ipaserver should be dropped and replaced by the one in ipapython.

> ipalib/util.py:
> load_plugins_in_dir
> import_plugins_subpackage

These were intended to make it more flexible to locate plugins outside 
of ipa.

> make_repr [in imports & its test only]

Not sure. Maybe Jason used this to make it easier to tell what was being 
imported.

>
> Some functions appear in more places and are the same:
> realm_to_suffix
> get_fqdn

Should be centralized in ipapython if practical.

What I'd suggest is to open a series of tickets to reduce and drop 
various bits.

rob




More information about the Freeipa-devel mailing list