Next on the list of tasks is updating the python handling, including use of pixi to install environments for plugins. (It handles both PyPI and conda.)
One key question is that many users may have Python already installed and may prefer to use that (e.g., for the input generators).
But clearly many users do not, and it causes confusion. I see two possible options, esp. for Windows and Mac users who have python binaries but they don’t actually work – they’re just a stub to install later.
We ask all users if they want to download & install Python on first launch
We try to determine if python is in the PATH if it’s one of these Mac / Windows “stub” programs and just install for them
Maybe there are other options… I’m probably going with option 1? Seems like on Linux / BSD platforms, it’s a safe bet that python is installed, but a lot of people use Mac and Windows.
The main catch would be that it requires a network connection, but we can set it so the install will prompt again if the downloads fail.
Approach 1), i.e. to ask during the installation of Avo2 if one would like to equally install Python is indeed advantageous because ideally the two processes are back-to-back: if school policy requires administrator privileges to install Avo2 on a computer pool, then the assistance by the IT help desk to equally launch the installation of Python (including addition to Windows’ $PATH variable) with this insight (and permission) is still present. The 28.8 MB (the current Windows 64bit Python 3.13.6 installer) likely still can (and may) be provided within the installer of Avo2, too.
Yes, this is cluttered (compared with a central package management in Linux) with then multiple full setups of separate Python interpreters which don’t know about each other. On the other hand, at least the 3.X series of CCDC’s Mercury in Windows (around Windows 7) used this approach regardless if i) one actually used the (subscription based) CCDC Python API, or ii) there already was another Python 2.7/3.6+ interpreter. Further, if e.g., a lab class/workshop requires Avogadro2, the IT help desk sees the logs to equally remove both Avo2 and its Python 3.x in one action, too.
The time frame of support of the Python interpreters is public (status table) and the development of Avogadro2 can schedule accordingly.
Yeah, we’ve had a few discussions about this. I could probably be convinced to go with 3.9 or 3.10 as the minimum version for the upcoming release. Unfortunately we know some distributions update very slowly.
As far as the Python installer, I’ve never figured out how to use NSIS to bundle both Avogadro and Python on Windows, though it should be possible.
Probably another step is to update the webpage to suggest that Python is highly recommended.
@ghutchis Discounting organizing a Python project around a pyproject.toml file with dependencies there (to help running an installation in a virtual environmant e.g., by a pip install .), so far, I had no interest in building an installer for Windows. Thus, I’m unfamiliar with the relevant techniques there. Just to be sure to have identified the same thing you describe, does NSIS refer to thisNSIS (Nullsoft Scriptable Install System)?
We use cmake to create an NSIS installer for Avogadro on Windows, although I’m open to other packaging options obviously (e.g., MSI, conda constructor etc.)
I guess another question is whether Windows users want standard install.exe versions or if other approaches (e.g., WinGet, etc.) would be useful.
The modern installer packaging format for Windows these days is MSIX. From what I’ve read, if Avogadro works as an MSIX, that should be the preferred choice. It apparently provides a pretty easy UX for both users and devs.
Programs packaged as an MSIX then install via the system App Installer, it’s easy to put them onto the MS Store, and they can be distributed via WinGet as well (I believe WinGet requires apps to be an MSIX).
Windows apps installed in this way run in containers, so like when creating the Flatpak, there might be one or two things (e.g. network access, plugin downloads) that need careful configuration. I believe this would mean that a Python interpreter/Pixi would have to be included in the app bundle for the interprocess communication to be allowed. See this page for restrictions.
For MSIX applications must also be able to install without user interaction so that they can be installed e.g. in an automated fashion or via the one-click install button in the MS Store. So I guess user choices for things like whether to install Pixi wouldn’t be obtainable, and the bundle would have to look more like the Mac/Linux bundles.