In general, we’ve bundled the input generator scripts with the main release - because they’re one of the most common features.
On the other hand, if you don’t have Python installed or configured, they won’t show up. It’s a common complaint (and I can see lots of people visiting various threads about it from searching Google and other search engines)
It makes a few things more complicated:
on Mac and Windows, many users need to install Python before they can get ORCA and other input generators to show up
we need extra logic to create a “default pixi manifest” and use it for the internal input generators
we need a special case to handle scripts inside the bundle vs. all of them being in the install directory
On the other hand… it’s one of the most commonly used features and people expect to see it when they install Avogadro.
As I work through the new plugin framework, at the moment the bundled generators don’t work.
My question is to get some feedback on whether we should require all plugins to be installed even the generators (e.g., pixi install will set up python, etc. for the generators).
As much as anything, these are the points that persuade me that installation should be required for all plugins, for now.
I believe I said before that it’s best IMO if, as far as possible, plugins won’t install if they won’t work, and plugins that are installed are assured to work. As in, catch errors with an environment in advance and refuse to install.
Aside from the better UX of it being an immediate negative result, obviously correlated with the user’s action, rather than a more confusing postponed one I think that “why won’t this plugin install for me?” is a much better troubleshooting request to have than “I’ve installed this plugin, why is it missing/not running?”. It’s easier to provide support for. The reasons why the installation might fail is mostly restricted to the things that we choose to catch, making it a finite list of reasons, defined by us, whereas there are a multitude of reasons why a plugin might not run correctly.
I think making things easier for now is really not a bad thing. I think asking people to download the input generators is a small price to pay for predictability. (And it doesn’t prevent bundling in future if a robust solution is found.)
Since it’s a big release and you want a good bit of accompanying fanfare, perhaps there could be a “Welcome to Avogadro 2.0” notice on start up that amongst other things mentions that the input generators are no longer included and need to be downloaded? That might soften the impact of removal from the bundle.
I had a brainstorm.. Since some people will develop plugins, the app should check directories anyway. At launch, it sees some un-registered plugins.
So it should pop up a dialog and ask “I found these new plugins, would you like me to install them” and indicate if it needs a network connection. Of course the user could say “never.”
In other words, we don’t want the plugin download feature to be the only way to install plugins:
plugin devs (including us) will want a way to install without downloading
someone may want to share an in-development package for testing
etc.
In short, the “bundled” generators (or xtb or anything else we decide to bundle in the future) will still be installed by the user. That can happen at first launch though.
I had assumed that the way to (re)install a plugin as a plugin dev would be via an “Install from file” option in the plugin manager. That way the plugin manager is still the gatekeeper, but the installation payload doesn’t have to be downloaded.
Regardless of whether you want to check for unregistered plugins at launch, I think the plugin downloader/manager having the ability to install from a file is extremely important in any case, because otherwise there is no way for a plugin author to test whether others will be able to install their plugin from the repository before they publish it.
The current installer of Avogadro2-1.103.0-win64.exe “costs” 114 MB to download. Would it be too costly if a future installer (for Windows) equally ships with e.g., the Python interpreter of python.org (e.g. python-3.13.12-amd64.exe is just about 29 MB)? For comparison, the installer LibreOffice_26.2.0_Win_x86-64.msi is worth 355 MB (reference).
I speculate during the installation process, the installer could probe if there is any / a not too-old Python interpreter around (as in: there is a record in Window’s PATH variable).
If present, continue with the regular installation of Avogadro2 including most popular plugins (like the generators) – if this is the designed goal of the installer.
Else if the Python interpreter is too old, or absent: inform the future user of Avogadro2 the installer will first install the recent Python interpreter which s/he now can accept, or decline. Let s/he know in advance that in the later case, some of Avogadro’s functionality will be not available. Avogadro then could still be e.g., a nice tool to build structures, fetch geometries from NIH/Cactus servers, provide appealing visualizations.
The interpreter by python.org web is meant as an example only; handy because of its name, and as a source of multiple interpreters for multiple operating systems. If the one by conda, or winpython, or another source provides a better fit here, go for it.
A potentially multi-step installation check/if needed installation of Python → set Avogadro2 → add extensions of Avogadro2 which tells/asks the user what is going to happen (re Python) might prevent accidental overwrite of an interpreter already set as default, and clutter of too many Python interpreters. Maybe such “Python autodetect” (for lack of a better word) then equally sets and briefly probes the path to the python executable Avogadro allows to adjust.
The problem is that none of us are Windows developers and I had that as an open issue for years without anyone offering to help. So I’m inclined to put the code into Avogadro rather than the installer. Also, it needs to work for Mac now that Apple isn’t bundling python by default.
I think in general, we’re leaning towards strongly suggesting pixi for most users because it can install Python, packages from PyPI as well as codes from conda-forge (e.g., xtb, crest, even antechamber for AMBER).
I’m somewhat inclined to have an installer that would include python as part of the base install along with @matterhorn103xtb package since there’s lots of interest.
As I said, I think the best way to handle that would be the first startup, realizing that there are packages to install, using pixi to download and install python and other dependencies.
@ghutchis I see, it goes back to (not only, but as an earlier example of) your query of Switching to pixi if available. I thought there would be an issue with a tag “help wanted” on GitHub for avogadroapp (no, not now), but pixi is a topic to avogadrolibs (such as here).
Ok; the installer eventually delegates Python relevant installations to pixi.
I think I asked some on the forum too. I’m sure there’s some way to do it with NSIS installer, but again, not being a Windows expert, it seemed easier to delegate to pixi
At the moment, there’s no “never” and I realize looking at my comment that I should add some information about “Installation may require downloading dependencies” or something similar.
If you click “Show Details…” you’ll get a list of each package directory, e.g.
I think this will be incredibly useful, it has to be said!
I’d suggest wording it in a way that clarifies that new/updated packages have been found locally, because otherwise it kind of comes across like it wants to download updated versions from the web, which may alarm some people.
Also, better to stick to consistently calling them “plugins” rather than “packages”, no?
Avogadro can generate input files for Gaussian, ORCA, NWChem, and other computational chemistry packages. This requires a one-time setup that will download and configure a Python environment (~X MB).
An internet connection is required.
(On Linux, the text would be somewhat different, since presumably python is installed.)
One thing that’s not completely clear to me: is this a message that will just be shown on first launch when people have downloaded an Avogadro edition than includes plugins, or does Avogadro check the plugin folders for unrecognised plugins on every launch?
At the moment, it checks on every launch. Of course for pretty much all users, that will only happen on first launch (i.e., to install the input generators).
It computes a hash of the pyproject.toml so it only happens with new changes.
I’m not sure if it’s entirely relevant, but when I was working on the syntax highlighting yesterday evening I found that, with my local build, I was essentially always prompted to install the plugins, even if I had already installed them and if I had not rebuilt since the last “yes”.
For plugins with a pyproject.toml you could theoretically check the version number, although I’ll be the first to admit I’m not always consistent with bumping version numbers in my own Python package.
I don’t actually think I touched any Python code. IIRC the only thing I changed was C++ code yesterday, and near the end I happened to slightly change the syntax json for NWChem to be up-to-date with the new options.
Since the files are getting hashed to check if they’ve changed, I’m wondering if the hashing is using just the file text or if it’s also using file metadata like, for example, file path or latest modification time. If it’s the latter, then it would make sense that it always prompts since the files are moved to another spot so their path and their modification times would be different than the source.
It’s hashing the text. At the moment, the avogenerators doesn’t have a pixi section, so it will run pixi init which changes the text as it’s registered.
I should probably add a pixi section so it happens less, but it’s generally a good thing that small modifications force the dialog.
But only changes to pyproject.toml, right? So changing the code itself won’t cause a prompt for reinstallation?
Not that it needs to – I think the way you’ve set things up means that both pixi and pip installation methods install the package as editable installations, so all code changes are reflected immediately.
Correct. As I said, the avogenerators doesn’t have a pixi section right now, so any re-build / reinstall for that will be different from the version registered.
