Public Methods

updating code

This routine packages what is needed to upgrade an older system to the current code. Code releases are numered

     p1n1.p2n2.p3n3...

where "." is added at the point the code moved to another branch of the tree. FIG, who provided the initial release of the SEED, will number all of their code releases as

       FIGn

where n is an integer. Suppose that between releases 13 and 14 a second group (which we will term "Idiots" for convenience) took release 13 and wished to branch the code tree. At that point, they would name their first release as

        FIG13.Idiots1

We are, of course, being both cavalier and nasty when we make such a reference. We do, however, wish to express the view that it will benefit everyone to attempt to reconcile differences and maintain a single code progression as long as possible. There are often good reasons to part ways, but we urge people to think carefully before taking such a step.

Two code releases

    i1.i2.i3...in
and j1.j2.j3...jm with m <= n

are compatible iff

    ip == jp  for p < m, and
    jm and im have the same "source" and
    jm <= im

A new code release must have the property that it can bring any "older" compatible release up to its release.

Note that there is an issue relating to the code to build/install packages. Since a system may be radically restructured between releases of code, the code to build a "package" and the code to "install" a package are radically separated. For example, the code in P2Pupdate.pm for building an assignment package and the code for installing an assignment package both apply to the release of code current on the system containing P2Pupdate.pm. In fact, the code releases may be quite different on two synchronizing systems.

To make things work the following rules must be observed:

    1. a code release is a tar file containing VERSION, Packages,
       bin/ToolTemplates, and CGI/ToolTemplates.  The installing system needs
       to place these at the appropriate spots, and then run bring_system_up_to_date,
       which is supposed to do any required restructuring.
    2. an assignments package is a tar file containing a single directory.  The directory
       contains subdirectories -- one per genome.  Each genome subdirectory contains zero
       or more files.  The name of the file is the "user" and the contents will be the
       assignments made by that user.
    3. an annotations package is a tar file containing a single directory.  The files in 
       the directory are named by genome. They contain the annotations for the genome.

what_code_do_I_have

usage: &what_code_do_I_have($fig_base)

This just returns the current version of the code.

updatable_code

usage: &updatable_code_code($v1,$v2)

    This just returns true iff the two versions of code are compatible and $v1
    is "more recent".

package_code

usage: &package_code($fig_disk,$file)

$fig_base must be an absolute filename (begins with "/") giving the FIG from which the updated code release will be taken.

$file must be an absolute filename where the "code package" will be built.

install_code

usage: &install_code($fig_disk,$package)

$fig_disk must be an absolute filename (begins with "/") giving the FIG to be updated.

$package must be an absolute filename where the "code package" from which to make the update exists.

Note that this routine does not check that the updated code is compatible, or even less current. It is assumed that upper level logic is doing that.

package_lightweight_code

usage: &package_lightweight_code($fig_disk,$file)

$fig_base must be an absolute filename (begins with "/") giving the FIG from which the updated code release will be taken.

$file must be an absolute filename where the "code package" will be built.

install_lightweight_code

usage: &install_lightweight_code($fig_disk,$package)

$fig_disk must be an absolute filename (begins with "/") giving the FIG to be updated.

$package must be an absolute filename where the "code package" from which to make the update exists.

Note that this routine does not check that the updated code is compatible, or even less current. It is assumed that upper level logic is doing that.

what_genomes_will_I_sync

usage: &what_genomes_will_I_sync($fig_base,$who)

This routine returns the list of genome IDs that you are willing to sync with $who.

package_annotations

usage: &package_annotations($fig,$genomes,$file)

$genomes is a pointer to a list of genome IDs that will be exchanged.

$file must be an absolute filename where the "annotation package" will be built.

install_annotations

usage: &install_annotations($fig_disk,$package)

$fig_disk must be an absolute filename (begins with "/") giving the FIG to be updated.

$package must be an absolute filename where the "annotations package" from which to make the update exists.

install_annotations_gff

Install a set of annotations contained in a GFF3 file package.

We parse using the FigGFF::GFFParser GFF parser. This returns a GFFFile object that contains the parsed contents of the file.

restore_annotations

usage: &restore_annotations($fig_disk);

$fig_disk must be an absolute filename (begins with "/") giving the FIG to be updated.

package_aassignments

usage: package_assignments($fig,$user,$who,$date,$genomes,$file)

$user designates the user wishing to get the assignments

$who designates whose assignments you want (defaults to "master")

$date if given indicates a point in time (get assignments after that point)

$genomes is a pointer to a list of genome IDs that will be exchanged.

$file must be an absolute filename where the "assignment package" will be built.

install_assignments

usage: &install_assignments($package)

$package must be a filename where the "assignments package" from which to make the assignment set exists

package_translation_rules

usage: &package_translation_rules($fig_base,$file)

$fig_base must be an absolute filename (begins with "/") giving the FIG from which the updated code release will be taken.

$file must be an absolute filename where the "translation_rules package" will be built.

install_translation_rules

usage: &install_translation_rules($fig_disk,$from,$package)

$fig_disk must be an absolute filename (begins with "/") giving the FIG to be updated.

$package must be an absolute filename where the "translation_rules package" from which to make the update exists.

restore_translation_rules

usage: &restore_translation_rules($fig_disk);

$fig_disk must be an absolute filename (begins with "/") giving the FIG to be updated.

unpack_packaged_subsystem

Unpack a packaged subsystem (from the clearinghouse or a p2p transfer) into a directory; this will create a directory named as the subsystem and formatted like the standard subsystem directories, as well as a file of assignments and a file of sequences in fasta format.

Returns the name of the subsystem.