> What would the installer feature do? It isn't clear what install > means, but the package.json, and run.py etc seem to make sense.
For many scripts, the install script won’t do anything. As an example, with Python, it could set up a virtual environment and test for required modules. Maybe your plugin uses ASE or pybel or cclib and it’s not available. So pop up a message and tell the user to run “pip install X”. >> their plugin scripts in *any* language as long as it meets the minimal API >> (i.e., pass back JSON for the dialog). > This feature was designed from the start to support any language, but > we never went beyond Python. The input/output is language agnostic, The catch is that the current scripts are foo.py. My suggestion is that we change them to directories, so it’s obvious that scripts can use more than one file, and potentially remove the extension. I mention using other languages because I want to make it super-simple for end-users (or research groups) to hack in their own personal scripts. Someone might want to use .. Fortran or C++ or JavaScript… I dunno. But if it’s just “run” or “generate” then it’s more obvious that other languages are allowed. > I think it totally makes sense to pull the JSON stuff into a separate > file, Yes, I think this is a big win for both localization and hacking (e.g., even people worried about Python might be willing to tweak the JSON). > To make it easier to implement I wonder if we want to explore adding > this more dynamic scripting interface as a new feature, then port the > input generators if it looks general enough for them too, and allowing > us to merge an earlier version that perhaps doesn't have everything > working. There are also the file format scripts, that could be in any > language too but are currently hardwired for Python. Yes, exactly. My approach was to refactor the input generators. So both the “action” scripts and “input generators” would work. I think the “package as a directory” feature will be needed for file format scripts like cclib. Eventually, my vision is to have a feature that goes to GitHub and allows users to download new file formats, input generators, actions, etc. > easier. We should also add support for running from home directory as > well as the system paths where the application gets installed. Right. This would be part of the plugin-loader feature I mention. You could point at a home directory that meets the requirements (e.g., package.json manifest) or grab online. -Geoff ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
