Better Python configuration

Development Design & Interface
1

Okay, I’m currently working on a better Python settings dialog…

  • It now finds all Python binaries in your PATH and indicates the version
  • It still lets you browse for a custom path

To Do:

  • It should add a “first launch” warning if it cannot find Python and suggest installing miniforge via link (e.g., depending on the platform)
  • It seems like it should check for conda or mamba and include a list of all environments
  • @matterhorn103 suggested it should prompt to create a new environment?
  • Anything else I’m forgetting?

New Python settings
New Python settings1012×598 96.1 KB

2

I have no idea why my Mac is ignoring the final ) character in the version numbers

Also, I have a python installed as /opt/local/mambaforge/bin/python but it’s a symlink and the code understands the duplication.

On Windows, it will look for python3.exe and python.exe

3

Looks great!

Perhaps an “Allow plugins/extensions to install required Python packages?” checkbox that determines whether the contents of a plugin’s requirements.txt get installed when the plugin itself is? It could be off by default.

4

That will be a separate pull request. In the download plugin, if it finds a requirements.txt file, it will ask before installing:

“This plugin requires certain packages to be installed.
Do you want to install them?”

Always | Yes | No

If conda is in the path, it will try:
conda install --file requirements.txt

Otherwise, it will use pip install -r requirements.txt

5

I had a moment to put together a pull request for this - not fully useful until the conda environment can be set:

6

I think from feedback here, if conda is found but only the base environment exists, the configuration dialog should query about creating a new environment for Avogadro, right @matterhorn103

Only the “base” conda environment exists.
Would you like to create a new environment for Avogadro?

[ “avogadro” ]

“Cancel” | “Okay”

I’m trying to decide if that should pop up at first launch … or

  • the configure dialog (i.e., it finds conda but only one environment)
  • the downloader (i.e., it needs to install requirements, but the conda environment hasn’t been set)
7

I suppose the third option makes most sense to me, as then you avoid asking the user until it actually becomes relevant. Asking on first launch would be confusing I think.

8

Can similar be done also when conda isn’t found, and no environments are found?

I.e. Suggest the creation of an avogadro environment with python -m venv avogadro

9

Well, one thing at a time.

Right now, I’d like to merge in what I have, and rigorously test it, which includes:

  • checking for python on startup and suggesting miniforge
  • using conda or pip to install requirements.txt for downloads
  • picking a python from PATH or conda environment

That still means that the code that runs python needs fixes to activate the conda environment. I’m sure there are probably some corner cases and bugs in what I have as PR.

Once that’s working, I’m willing to look at venv and other environments. My main hesitation is that venv can be anywhere.

If you (or others) want to help with research / feedback on how venv support should work… I’m open to it. (For example should every plugin have its own venv then?)

10

Err, I’m not sure that came across well.

I’m absolutely willing to support venv … but I’d like to merge the conda work first, and I’m not entirely sure how venv support should work.

  • create a venv for each plugin
  • find existing venv to re-use … but how?
  • create a venv for Avogadro in a standard location
  • ???
11

No don’t worry, didn’t come across badly. I agree taking it step-by-step is good. Just thinking for the future :slight_smile:

Go ahead and finish the conda stuff for now. When it comes to testing I am very happy to lend a hand.

I’ll have a think and a read on how we can manage venv.

Not sure we need one for each plugin. What advantage would that have? It could lead to excessive duplication of things like numpy, which would suck.

It’s a good point about the possibility of them being anywhere, I’d forgotten that.

I guess Avogadro doesn’t really need to do automatic detection of venv environments. If the user wants to use a specific one they can manually configure the location. I would instead suggest that the possible location of a venv only becomes relevant when a plugin needs dependencies:

  1. If conda was found or specified by the user, and a conda environment is specified, dependencies are installed to that (if the user wishes)

  2. If conda was found but no environment is specified, Avo suggests the creation of a conda environment called avogadro

  3. If the Python binary path is not a conda installation, but a venv environment was already specified manually in the Python config, use that

  4. If no venv has been found, suggest the creation of a venv called avogadro. Probably best to put it in the plugins directory or some other user data directory.

If the location is kept consistent, then if a user agrees to make an avogadro environment (with conda or venv) then Avo can first look if there’s already one and use it. In this way the environment could be persistent between reinstallations or updates.