Open rheiland opened 2 years ago
I agree on having both /addons
and /plugins
in the top level directory.
On where to house sample projects for the plugin, I think it makes more sense for those to be in /plugins/[plugin-name]/sample_projects
or some such directory to minimize setup for users downloading the plugin. I.e., they just unzip the plugin folder and move it inside /plugins
.
Note that there shouldn't be a need for a compiler macro since there will won't be any abstract and concrete classes as with intracellular. Rather, a Makefile for a sample project using a plugin will simply provide the necessary paths and names of the new files and possible libraries.
I don't understand this part. Can you confirm PhysiPKPD matches this description?
We want to have a community discussion about future extensions to PhysiCell. We begin by discussing the existing "addons" extension for intracellular models and then discuss a possible "plugins" extension.
As of PhysiCell 1.10.4, we have "officially" supported addons:
and it happens to be the case that these pertain to intracellular models. How? Well, each of the 3 types (boolean, FBA, and ODEs) provide concrete C++ classes which implement the same API to the abstract
class Intrarcellular
defined incore/PhysiCell_phenotype.h
(as a reminder, an "abstract" class declares all its methods asvirtual
and those methods must be defined in any derived concrete class). For example, in/addons
, we have these concrete classes:and then each of the three types of concrete intracellular interfaces provide a similar directory structure and files, e.g., for ODEs/libRoadrunner, we have:
When a specific PhysiCell-intracellular model is compiled, it needs to provide information in its Makefile that will say what type of intracellular library will be used.
The PhysiCell distribution provides sample intracellular projects and each project provides a Makefile which uses a g++ compiler macro (
-D ADDON_*
) that defines which type of intracellular model is to be used:Should we distinguish "addons" from "plugins", by saying that addons are limited to officially supported, cross-platform, intracellular libs and “plugins” could be “community supported” code with, perhaps, a library which is not fully supported cross-platform? If so, we should define minimally required info for any plugin, e.g., a README.md and a sample project.
Could we agree on having both an
/addons
and a/plugins
directory in the top level PhysiCell directory, with unique subdirectories for each plugin under/plugins
(similar to what is done for intracellular)? And should we define a/sample_projects_plugins
at the same directory level and following the template of/sample_projects_intracellular
, or should sample projects be provided under each/plugins
? Note that there shouldn't be a need for a compiler macro since there will won't be any abstract and concrete classes as with intracellular. Rather, a Makefile for a sample project using a plugin will simply provide the necessary paths and names of the new files and possible libraries.