Patch for adding version info for Extensions

[Bernhard Herzog]

Jan-Oliver Wagner <jan at intevation.de> writes:

> I decided to have a explicit registration for the extensions.
>
> Let me know what you think.
>
> Attached is a patch (based on current CVS HEAD) and a new
> file Thuban/UI/extensionregistry.py
[...]
> class ThubanExtensionDesc:

I'd omit the Thuban prefix from that name.  If ExtensionDesc is too
ambigious in the code that imports this, that importing code can always
use import ... as... to choose a different name.  This applies to
ThubanExtensionRegistry, too.

>     """
>     A description of a Thuban Extension.
>     """
>
>     def __init__(self, name, version, authors, copyright, desc,
>                  min_thuban_versions):
>         """
>         Initialize a new Thuban Extension information.
>
>         name -- The name of the Thuban Extension.
>                 Example: 'gns2shp'
>
>         version -- The version number of the Thuban Extension.
>                    Example: '1.0.0'
>
>         authors -- List of authors.
>                    Example: [ 'Jan-Oliver Wagner' ]
>
>         copyright -- Copyright notice.
>                      Example: '2003, 2004 Intevation GmbH'
>
>         desc -- Short description of the Thuban Extension.
>                 Example: _('''
>                          Converts GNS (Geographical Name Service of NIMA)
>                          to Shapefile format and displays the data.
>                          ''')
>  
>         min_thuban_versions -- Minimum Thuban versions required to
>                                run the extension. This is a dictionary
>                                where the major release numbers ('X.Y')
>                                are the keys and the minor release
>                                number is the contents (e.g. 'Z').
>                                Example: { '1.0' : '0' }

I asked Jan yesterday why he chose this representation.  His goal was to
make it possible for an extension to state that it can use e.g. 1.0.1
and later from the 1.0 branch and 1.1.2 from the 1.1 branch.  That is,
neither 1.0.0 nor 1.1.1 would work, but 1.0.3 and 1.1.5 would.

I have two issues with this:

1. Should we support it at all?

We only need this if we backport features from newer Thuban versions to
an older one.  Currently this would mean that we backport from cvs HEAD
to the 1.0 branch.  

2. Is this the right representation for the interface of ThubanExtensionDesc?

I think it's too complicated.  I suggest the following, using the same
versions as in my example above:

   [(1, 0, 1), (1, 1, 2)]

That, is a simple list of versions, with each version a tuple of
numbers.  Representing a single version as a tuple of numbers has the
advantage that we don't have to parse the version numbers anymore and
comparisons are done numerically.


> class ThubanExtensionRegistry:
>
>     """
>     A ThubanExtensionRegistry keeps information on the registered
>     Thuban Extensions.
>
>     The registry will raise a exception either when the version
>     required for the Extensions exceeds the version of the currently
>     running Thuban or if the name of a registered extension already
>     is used for registering another extension.
>     """
>
>     def __init__(self):
>         self.registry = []
>
>     def Add(self, ext):
>         self.registry.append(ext)
>
>     def Get(self):
>         return self.registry

I'd lose the Get method and implement some others instead which match
the usage of the registry better.  See below.

Another thing: I think the Add method should be spelled add, that is all
lowercase.  The main reason is that I think we should, in the long term,
adopt the more common naming styles used in python code.  For Thuban
this basically means not to start method names with upper case letters.
For Thuban this would be a substantial change and even though it would
be easy to retain the old method names for a while for backwards
compatibility it's not something that should be done soon.  OTOH, for
small new classes such as this or the ClassMapper it wouldn't be a
problem to adopt that naming scheme and, in fact, ClassMapper already
uses it.

> --- Extensions/gns2shp/gns2shp.py	18 May 2004 21:09:50 -0000	1.3
> +++ Extensions/gns2shp/gns2shp.py	29 Jul 2004 12:24:53 -0000
> @@ -32,8 +32,22 @@ if __name__ != '__main__':
>      from Thuban import _
>      from Thuban.Model.layer import Layer
>  
> +from Thuban.UI.extensionregistry import ThubanExtensionDesc, ext_registry
> +
>  import shapelib
>  import dbflib
> +
> +
> +ext_registry.Add(ThubanExtensionDesc(
> +    name = 'gns2shp',
> +    version = '1.0.0',
> +    authors= [ 'Jan-Oliver Wagner' ],
> +    copyright = '2003, 2004 Intevation GmbH',
> +    desc = _("Converts GNS (Geographical Name Service\n" \
> +             "of NIMA) to Shapefile format and\n" \
> +             "displays the data."),
> +    min_thuban_versions = { '1.0' : '0' }))

That min_thuban_versions is wrong.  1.0.0 doesn't have the extension
registry :) The same applies to the other places where you call
ThubanExtensionDesc.


> --- Thuban/UI/about.py	26 Mar 2004 18:15:35 -0000	1.12
> +++ Thuban/UI/about.py	29 Jul 2004 12:27:14 -0000
> @@ -70,6 +72,14 @@ class About(wxDialog):
>              text+= '\t%s %s\n' % (name, version)
>          text += '\n'
>  
> +        text += _('Extensions:\n')
> +        if len(ext_registry.Get()) == 0:

I think we should implement either __len__ or __nonzero__ in
ThubanExtensionRegistry so that you could write

 if ext_registry:

instead.

> +            text += _('\tNone registered.\n')
> +        else:
> +            for ext in ext_registry.Get():

And this would be easier written as 

    for ext in ext_registry:

by implementing a suitable iter method as e.g. a generator.

Of course, you could also do:

  for ext in ext_registry:
      text += ...
  else:
      test += "None registered"

Then we wouldn't even need __nonzero__ or __len__ yet.  Although __len__
would probably be useful anyway, although I'm not yet sure that the
number of registered extension is really the same as the length of the
registry, that is whether it might not be better to add a length()
method for that.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/