TODO.txt

Things to clarify
=================
- fetch_data doesn't give a good error message if the argument you give it is 
  wrong  (e.g. running ``pull_into_place fetch_data workspace_name`` from 
  within ``workspace_name``).

Regarding fragment generation
=============================
The fragment script uses hard-coded paths to Roland's rosetta checkout and a 
number of databases.  I should modify it to to rosetta on the paths either from 
the command line or a config file, which PIP should supply.

Regarding annotating output structures
======================================
It would be nice if rosetta scripts had a way to specify filters that run on 
the pose and add to the PDB in the end, using setPoseExtraScore() or whatever 
it's called.  This could be parsed in a general way by show_my_designs.py

Regarding the wildtype structure
================================
Save input pdb as 'wildtype.pdb.gz'

Generate 'input.pdb.gz' or 'design.pdb.gz' or 'mutant.pdb.gz' in the 01_setup 
scripts by running fixbb on the given wildtype structure.  First, parse the 
restraint file to figure out which residues are restrained.  Second, parse the 
lines from resfile that pertain to those residues.  Make sure that those lines 
are of the form 'PIKAA .', i.e.  make sure that each restrained position can 
only be one type of residue and that that type of residue is specified in the 
resfile.  Combine the parsed resfile lines to make a mini-resfile and feed that 
mini-resfile to fixbb to generate the input pdb.

or

Prompt the user for a relaxed wildtype structure.  Then make the following 
modifications to the model building script: begin with a quick repack using the 
given resfile, follow by applying constraints, then do full-atom loop modeling.  
Currently, the model building script has to load constraints from the command 
line (which means there can't be an initial repack step) because otherwise the 
centroid mode loop modeling chokes.  This scheme skips centroid loop modeling, 
which may or may not be a problem.  I can always explicitly add it back in, 
though.

A conceptual problem, however, is that the "wildtype" structure would not be 
wildtype if you wanted to add or remove residues in your designs.  So in this 
sense it's more honest to call the structure "input", because that's what it 
is.  I could call it "reference".  That's maybe even more what it is, because I 
use it to calculate loop RMSDs, delta buried unsats, and things like that.

In view_models.py
=================
This script is very nearly a general utility for viewing directories full of 
structures, but it's got a few things making it PIP-specific (and even 
Kale-specific).  I should get rid of these things and make it a general 
utility, then I can include it in PIP as a submodule.

To decide which axes to plot, I should looks for look for particular comments 
in the PDB.  It's possible that not all the PDBs will have the same comments.  
I should add a status bar along the bottom to inform the user when not every 
PDB in the directory could be plotted.  It's also possible (even likely) that 
there will be no PDBs with scores or RMSDs in the directory.  What should I do 
in that case?  I pretty much have to crash nicely.  I'm not sure there's a way 
to recognize axes in a general way.  I can have a general format that I expect 
(so that tools like PIP can feed me axes), but to be useful I'll also need to 
recognize loopmodel output.  There probably isn't a way to recognize general 
rosetta output.  General axis info format ideas:

REMARK AXIS Total Score -352.53     # Split at right-most space

The default previewer (I like the term "previewer") should just open the model 
in pymol.  Maybe I can also have a default previewer that opens the model in 
chimera.  Users should be able to add their own previewers by specifying 
arbitrary scripts.  The script will be called with the absolute path to a PDB 
as its first and only argument.  For the Cas9 project, I would have written a 
script that runs pymol, loads the given PDB, loads the wildtype PDB (hardcoded 
path), formats things nicely, and launches wt_vs_mut.  The question is how 
should view models remember that script?  Also, how should it decide what to 
call it?  Regarding the second question, we can look for a magic comment and 
fall back on the file name if necessary.  Regarding the first, we either need a 
config file or a magic naming scheme.  I want to be able to easily use the same 
script for multiple directories, like I would for Cas9 project.  If I'm going 
to use a magic name, I can get rid of the 'Add Custom Previewer' button.  Or I 
can keep it and just have it describe the magic naming rules.

Right now the previewer knows the loop and the resfile from the workspace.  
That logic would have to be moved into a one-off script, that actually could be 
included with PIP if I use the magic naming convention.

The view_models.py script should accept any number of paths on the command 
line.  Directory paths must contain at least one PDB file, and file paths must 
be PDB files.