But because we initially envisioned the Protocol Library to host complete and ready for production/usage code examples I wouldn’t consider a tool that requires heavy modification by end users as a complete automated Protocol (aP).
What do you guys think about?:
Placing tools / code of wide applicability into a “PLR Cookbook”? (@rickwierenga initially suggested this to me)
…thus is the space for code snippets, code to inspire, code that requires modification before production.
Complete “ready for production” code (ELISA, PCR preps, DNA preps, normalisation runs,… ) into the “Protocol Library”?
It seems to me that there is a clear distinction between tools and ready to use code, and I didn’t see the need for an extra Cookbook initially but this is changing my mind
This is exactly what I was thinking with the proposed file structure, but perhaps we could organize it differently, there are many solutions so we can provide a scaffold via a ‘build your own’ (think modularity like legos), and then the 'plug 'n play section can be just that, I do however think that it is important to group things by Liquid Handling function because then the user is more readily able to use more of the code instead of having to go and dig through files for code that supposedly conveys the same protocol idea.
For Example, If a user were to come up with an elegant solution to a golden gate plasmid mapping, and it was more efficient than simply using a single pipet tip, then that should be shared, but if it is only in one section, it might be missed. I say that because there will be no true librarian of the aP library, and if people are going to add their own protocols, then it might be hard to find adjacent protocols and efficiently transfer information if they are not group via LH function.
@CamilloMoschner
Another idea that we can start with here is including a requirements.txt file for a virtual environment for each aP, and including the generation, activation, installation, and deletion of a python virtual environment–which pulls exclusively from the versioned requirements.txt–as commands in the notebook cells. Using notebooks would also allow this modularity.
I agree with Rick that ideally any protocol tracking should be general, incorporate version data, and have good data sanitation. I’ve been working on an approach that uses type hints of any general python function in a given folder or git repository, maps the function calls within it in the same manner, and constructs database entries tied to these. With decorators, you can specify additional constraints easily. You can find more details in my recent forum post:
This is definitely in a very early stage – although I have been working on this off and on for over a year, it still has a lot of work remaining but I have learned a lot of lessons along the way. I would love to hear people’s thoughts about how we might incorporate some of the ideas and concerns raised in this thread.
