DNAAssembly with OneStepGeneExpression breaks when used with a default Mixture

[sclamons]

Use case:

• I'm building a simple gene expression network with DNAAssemblies, using OneStepGeneExpression for gene expression.
• I'm working with a Mixture instead of an ExpressionMixture, because I'm an unsophisticated user who doesn't know about ExpressionMixture and wants to implement it myself.
• I make some component, make that component the protein in a DNAAssembly, and put them into a Mixture along with a OneStepGeneExpression object and an EmptyMechanism object (for translation) and all the appropriate parameters.

What I expect to happen: I should get a reaction [gene] -> [gene] + [protein].

What actually happens: I get no reaction.

What causes the bug: my DNAAssembly object creates a default promoter object on construction, which comes with a default transcript. When OneStepGeneExpression tries to produce a transcript, it... finds something with the wrong name and fails to produce a transcription reaction?? I'm not exactly sure what fails at this point, but I know that the problem happens when the DNAAssembly's Promoter object has a transcript (default, named after the promoter, which itself is named after the DNAAssembly it's attached to) that doesn't match the DNAAssembly's transcript (which should be None).

A manual fix, which ExpressionExtract uses, is to call my_assembly.update_transcript(False) after creating a DNAAssembly my_assembly. This works because update_transcript correctly sets the DNAAssembly's promoter's transcript... but only if that promoter already exists. update_transcript does get called in DNAAssembly's constructor, but at the time it's called, the promoter doesn't yet exist.

I can see two possible interpretations of this bug, implying different fixes with different advantages, and could use some feedback about which to use:

1. DNAAssembly has an edge case that we haven't considered. To close the hole, we need to call update_transcript again in DNAAssembly's constructor a second time, after update_promoter, OR specifically check for this case in the DNAAssembly constructor and manually set the DNAAssembly's promoter's transcript if necessary.
2. Promoter objects shouldn't, by default, produce RNAs. A Promoter with transcript=None should have no transcript, and Components that use Promoters to do things should be responsible for giving them correct transcripts. In this case, we need to change the default behavior of Promoter, then make sure all the things that use Promoters handle their transcripts correctly. I'm 90% sure DNAAssembly will immediately work correctly even if we make Promoters default to no transcript, so I don't know how much work this will take.

Thoughts?

[WilliamIX]

In general, I am (and have always been) dissatisfied with how OneStepGeneExpression works because it is kinda hacky and requires some manual configurations in ExpressionMixtures (this is completely my doing, but I have yet to come up with a good solution). This issue gets more complicated when you consider regulated Promoters which say, use hill functions to regulate transcription. In this case, the Promoter (& Assembly) and all the transcription Mechanisms need to somehow know that transcription and translation are not being modeled separately in order to work....working through this resulted in the convention you have stumbled upon where transcript = None but protein != None results in all the built-in transcription methods expressing the protein.

I don't immediately see any problems with the first fix. The second fix, unfortunately, will break DNA_construct which makes extensive use of Promotors storing the transcript(s) they encode for. The edge case you are discussing was dealt with in ExpressionMixture constructor by manually going through DNA_assemblies and setting all the transcripts to None.

I think the goal of making those Mechanisms work in general Mixtures is a good one and this issue definitely highlights a weakness of BioCRNpyler. I think there should be a way to make Expression systems work more seamlessly.

[sclamons]

Regarding fix #2, it's fine for Promoters to store their transcripts, I'm just proposing that we might want to change how they handle default transcript names. If DNA_assemblies need Promoters to use named transcripts, they should be able to tell them what those names are, right?

[sclamons]

We'd have to do some rewriting for sure, though.