One “catch” for a lot of Windows users is that Avogadro2 uses Python fairly heavily.
My suggestion if python or python3 are not found on first launch, Avogadro should pop up a link to download miniforge since that includes a base install of Python and makes setting up environments easier.
e.g. https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Windows-x86_64.exe
Thoughts? Alternatives?
Isn’t this also an issue for macOS, as Python isn’t bundled with it any more (and it was only ever bundled with Python 2 anyway)?
The main sticking point I can see with the miniforge suggestion is that the same package often has different names in the Conda and PyPI ecosystems (pytorch vs torch being the usually cited example). Conda also uses a different syntax (i.e. not PEP 508-conform) for dependency version specification strings, so the same dependency list can’t be used for both Conda and PyPI installs. So how would plugins specify their dependencies in plugin.json?
Would they have to provide two lists, one for Conda and one for PyPI?
Would the plugin provide only a list of PyPI deps and Avogadro would always install dependencies using pip/some alternative from PyPI into the user’s environment (with permission of course), even if the environment was a Conda environment? It is possible to install from PyPI into a Conda env, but it is explicitly noted as having the potential to cause issues.
Would Avogadro choose one of Conda and PyPI as the supported ecosystem and then only install dependencies for the user if the user is using the supported tool? And otherwise tell the user what dependencies are being requested and leave it up to the user to manually install?
No, Mac has had python3 for ages. I looked, and it seems in recent versions, running python3 will prompt to install the command-line tools.
Possibly. I hate this whole headache in the Python infrastructure, even though I see some are working to address it (e.g., pixi and uv).
When Paul and I were discussing the Python plugin API, etc. he was pushing for PyPI only. The problem is that a lot of science packages are only available on conda-forge (e.g., xtb and crest) because PyPI is python-only, but conda-forge is pretty flexible.
No. We will need to support both. 
The current setup should detect if conda is installed (although I need to add mamba and micromamba as alternatives 
) and you can select which Python you want to use. If that’s a conda environment, use conda. Otherwise, use pip.
Right now, we’re largely requiring users to install dependencies, which is fine for many of us, but not great for new users.
I’m open to suggestions, which is why I created the discussion thread.
Hmm ok, and this is also prompted if Avogadro tries to run python3 on a mac that’s currently python-less?
Sticking to PyPI would have been my instinct too really tbh. xtb and crest binaries are self-contained and easily obtained via curl-type requests; I don’t know how true that would be for other chemistry stuff though as I have little experience there.
I have had the impression though that conda is much less essential ever since wheels were introduced and PyPI packages can include non-Python stuff within them, e.g. conda isn’t needed for things like numpy any more. But as I said, not much personal experience. You use conda right? So you’re much better placed to assess that.
Well since you ask… At the risk of sounding like a paid advertiser of the thing 
the idea I would pitch would be to bundle uv with Avogadro, as I think it would basically solve all issues:
~ (/equivalent) so admin rights are not requireduv run script.py and uv would handle it allBut I’m not wedded to it, I can imagine that pixi might have all the same advantages + conda packages on top, and it’s certainly also small enough to be bundled.
Just to throw my two cents into this since I believe neither of you are windows users (no taxation without representation!), I think that installing Python3 from the raw website is easiest. Having been an avid user of Python for many many years now, I have never had any problems just hopping into the python website and just downloading the installer. It is also simple from there to use the command line to install pip, if it is required.
If as you say, @ghutchis, that there are certain python libraries that are not accessible without a certain package manager, then that is a different story, and I would recommend the package manager that will work for everything.
There is also perhaps the possibility that I have simply misunderstood what you all are referring to w.r.t. the python requirements, which I encourage both of you to correct me on!
Sure, in principle that works fine, and one simple option would be that Avogadro could just point users in the direction of python.org if no interpreter is found.
Certainly the main issue is that users are currently unaware when problems they are having are due to missing Python, and that could certainly be improved to some degree through communication to the user – a warning on first start if no interpreter is found, and informative errors and hints when functionality that requires it is used.
My understanding of the original motivations for making use of some other solution were:
venv, and pip is widely considered to be a pain, and I can imagine it’s only more complicated for Avogadro to do it via system callsGeoff probably has further points to add or corrections to make.
Key for me is the consideration that most users of Avogadro don’t know anything about Python, may well have never heard of it, and might not be able to set it up themselves correctly. I know that as a kid/teenager I was baffled/frustrated by requests by software to install a Java virtual machine or a C++ runtime.
I think that’s a good summary. Basically, Avogadro doesn’t want to be in the business of forcing Python choices on people, but particularly on Windows, it’s crucial to help users install something.
Yep. And Java was the worst, because it had like a gazillion updates that would pop up all the time.
In principle, the Avogadro plugin system doesn’t even care about Python. It’s just that at the moment, there are a lot of Python users and a particular overlap with people who might want to use Avogadro.