Skip to content

v0.19.0

Compare
Choose a tag to compare
@github-actions github-actions released this 07 Sep 00:34
· 27 commits to main since this release
f415a47

Release notes

BREAKING CHANGE: Renamed IDT-specific fields

Some names related to the DNA synthesis company IDT have been renamed to be more general. You will have to rename these in your own code for it to run:

  • class IDTFields --> VendorFields
  • field Modification.idt_text --> Modification.vendor_code
  • field Strand.idt --> Strand.vendor_fields

Additionally, some keys in the JSON format for .sc files have changed as well. Scadnano (both the web interface and the Python package) should be able to read files with the old keys and convert them to the new keys upon saving. However, if you are manually editing the .sc file then use the new keys.

Some IDT-specific methods remain, such as Design.write_idt_plate_excel_file. These use the values in Strand.vendor_fields and Modification.vendor_code, but since the file format actually is specific to IDT, the method name is unchanged.

Although currently there are no methods for exporting to file formats recognized by other synthesis companies, in the meantime it should be straightforward to use the values in VendorFields to write custom code for such exports.

Field Modification.id removed

Previously, scadnano used Modification.id as a unique identifier for modifications.

The field id has been removed. Now, the field vendor_code is used as a unique identifier for the modification, where id was previously used.

Previously, if no id was specified, but vendor_code/idt_text was, then id was set to the latter. Such code should continue to work unmodified. But code referencing id should now refer to vendor_code instead. Additionally, if a script used the same vendor_code for different Modifications, then this will break. Each Modification should now have a unique vendor_code field.

Note that some vendors such as Eurofins use the same code for 5'/3' modifications (see issue #283). For this reason, the modifications internally are stored in a way that encodes their location (5', 3', internal). But for any two modifications of the same "location" (both 5' modifications, both 3' modifications, or both internal modifications) the vendor_code must be unique to the type of modification.

Commits