Attending:

Gerry, Eric, Dave, Anzar, Vijay Peter (via email)

Agenda:

1.  XML Schemas:
  a)  Overview of the ConfiguratorFactory XML Extension system
  b)  Defining an XML structure to contain Configurator Schemas.

2. Coding Standards
  a) Comment/Discussion on the Coding Standards drafts
  b) Plan for pylinting the Shahkar package


Minutes:
1.  XML Schemas:
  a)  Overview of the ConfiguratorFactory XML Extension system

     Desired behaviour --
            Not to subclass BaseConfiguratorFactory

     Default behaviour --
            Read all XML files in a directory, include
            an off switch for people who want to subclass.
            Subclassing becomes obsolete.

     Derived packages --
         -  How to add extension xml files for  McRunjob, D0Runjob etc...
         -  Put a directory in SHAHKAR_SEARCH_PATH
         -  Adopt a naming convention for factory xml files:
                ConfiguratorFactory*.xml
         -  Recommend a single XML file per package,
            but this does make it possible for a set
            of files to be used, or even one per configurator
            In this case the multiple files are chained and read.

     Peter Love:
         What is the entry point for derived packages?
                The entry point for the experiments is adding a dir to the
                SHAHKAR_SEARCH_PATH containing their XML files
          Can Select be avoided?
                  <Open question>

b)  Defining an XML structure to contain Configurator Schemas.

     Gerry Protests: Principal -> XML files to define things in
     configurator, macro files to define cfg, contexts to define
     cfg => Too many places that conflict. Hard to debug

     Suggestion --
         -  Disallow additem from Macro & Contexts,
         -  Only allow defines in macro/context.
         -  What is the use of defining a schema for
             a configurator, when 50 additem commands happen
             in the user scripts.

     Alternative: Use a python metadata schema module to define
                         schemas for configurators. (See MCPS)

      Consensus:
         -  If XML is used for Schema, then it should be the only way to
            define a schema.
         -  More discussion on this is needed!


2. Coding Standards
  a) Comment/Discussion on the Coding Standards drafts
  b) Plan for pylinting the Shahkar package

  Gerry's summary of test on Shahkar:
    Some bugs are reported which we simply cant fix at the present time:
      - Relative imports,
      - ** magic etc
      - Unused function arguments sometimes required.
   These tests cant be turned off either

   Hardest thing is fixing indentation
   -  Emacs has a tool for converting tabs to whitespace
   -  Recommend: do whitespace slowly in sections, maintain the block
structure

  Default was too tight for shahkar, adjust to avoid breaking interfaces
  with McRunjob.

  Allow more function statements, more returns, more variables
  Allow method names to start with capital as well as lower case
     - new version of .pylintrc file will be sent out today
incorporating these
       changes.

  Plan:   All new code to be pylint compliant

  Converting code:

  Gerry has done:
       NewLoader,
       ShahkarException
       XMLFactoryLoader
       BaseConfiguratorFactory
   Down to ignorable warnings as listed above

   A matrix detailing the Core modules and their status will be created
  and sent
  around. Start on a volunteer basis until everyone has an allocation
  Original Authors should be first choice for modules to make sure the
  comments are good.

  Code Groups:
     ShahkarParsers, BaseLinker, BaseConfigurator, BaseFramework  modules
     should be done together.

 Essential Check in proceedure:
     pylint, pychecker, run tests, check in.

  - Make a new CVS tag before we start changes so we have something
    to fall back on.
  - Anzar and Eric to look at creating a development branch for this.
  - Gerry to investigate packaging of pylint so that people can use it 
    without installing it into /usr/bin /usr/lib