Releases: nleroy917/optipyzer
v0.2.2
v0.2.1
v0.2.0
v0.1.4
Small changes were made to the server code to remove unnecessary functions and change parameters to make them more consistent:
- Dirichlet priors calculation code was removed altogether
- Remove calculation that raises frequency to prior parameter
- Remove
** (parameter - 1)
fromfrequency[species][codon]
calculation - Remove code that raises 10 to the power of
RCA
- Change value of
et
to0.05
in absolute difference calculation - Allow clients/users to specify number of iterations when optimizing a sequence
v0.1.3
v0.1.2
v0.1.1
Overview
Minimal changes were made. Only two updates were added. This is trying to do some clean up in preparation for an applications note.
Remove Dirichlet Priors From Averaged Codon Frequency Table
Caleigh and I were discussing the necessity of calculating the Dirichlet Priors when creating the new weighted table for an optimization query. It seems that it is an artifact of the original project and there is little rationale for its inclusion. Thus, for now, it will be commented out.
Styling Updates
I am not sure what happened, but the landing card got messed up. Maybe something happened with my tailwind version or a type was made. That was fixed. The software version was also included in the homepage.
Changes made with PR #33
v0.1.0
Overview
The three main facets of this project have needed considerable reworking since I first published this to GitHub. The server, the web interface, and the python interface all had significant shortcomings and oddities that were introduced by myself years ago when I first developed this. The web interface was revamped a few months ago to leverage next.js
and TypeScript which really improved performance and maintainability (as well as introducing a much better design...)
However, the server and the python interface still needed work. These are both addressed in this release.
The Server
I completely gutted the server architecture and introduced a few things that I feel will improve the maintainability and robustness of this project for a while.
FastAPI
I exchanged the Flask server framework for FastAPI. While Flask is great, I feel that FastAPI is just a little better and has a much better developer experience. I set up dependency injection and data validation and many points in the server to
prevent errors and provide users with as much information as possible.
SQLAlchemy
I swapped out the raw SQL
queries I was making for an ORM -- SQLAlchemy. Some may think that an ORM is overkill for a small project like this, but I think it can really go a long way to, again, improve the developer experience as well as maintain code readability and type hinting.
Core Engine Updates
The core engine itself was not touched. That code is pretty impenetrable. Rather, all wrappers around it and data-fetching functions were updated to support the above changes and get rid of some very old (like 3 years) legacy code that was left-over from another lifetime.
The Python Interface
I watered down the python interface just a bit as I realized it didn't need to be so complex. I also added type hints, function return models, and some example code. I believe I introduced some better data validation and error handling as well.
Conclusion
Hopefully, these changes make the code easier to navigate, easier to debug, and most importantly, easier to maintain in the future.