Add project preferences

[goanpeca]

• Include support for configuration setup (Global vs. Project)
• Hide configuration that do not make sense to display for projects (if user selects Project level config)
• Include project configuration on the preferences
• Add entry to the Projects menu to change configuration of the current project.

• Environment variables: Aqui debería ir una tabla con las variables de entorno definidas en el proyecto, junto la posibilidad de añadir o eliminar variables
• Packages: Aquí debería verse la lista de paquetes guardados con anaconda-proyect
• Conda Environment: Aquí debería verse el conda env asociado al proyeto, pero de pronto podemos unir esta entrada con Packages
• Master file: Este es el archivo maestro para correr el proyecto (edited)

[ccordoba12]

@dalthviz, did you find the notes I gave you in January for this?

[dalthviz]

@ccordoba12 I searched but I didn't find them :/

[ccordoba12]

Ok, no worries. I'll try to remember what I was thinking about it.

[goanpeca]

@ccordoba12 could you paste the paper here :-) ? thanks!

[goanpeca]

I still need to update icons and the actual logic for environments (a separate PR for anaconda-project). Is this what you had in mind @ccordoba12?

Environment and packages

For this one I think the user should only be able to change the package from the last option? A user using the default spyder env or another env should not be able to modify this since these other envs might not be handled by anaconda project at all. Also, how should we signal, conda vs pip ?

My idea is to have add create a small dialog where we can validate input and then populate the table. Clicking on the table for edition would pop up this dialog. I think this makes the process easier, since we can validate at the dialog level and not the table level.

Thoughts @ccordoba12 ?

[goanpeca]

We could also add something related to Version Control which could be a separate page, or be part of the general one? Information to display here could be the remotes of the project? or the original repo it was cloned from (if the project was created from a git clone).

Where should we include the Use Global Preferences vs Use Project Preferences option? in the general page?

[goanpeca]

@jnsebgosselin do you have some suggestions for the icons we could use :-) ?

[ccordoba12]

Is this what you had in mind

Yes, this is pretty much what I had in mind! Thanks!

About your screenshots:

• The "Variables" entry should be renamed to "Environment variables" to be quite clear about the meaning of that.
• The "Environment and packages" entry should be renamed simply to "Conda enviroment" and it should be deactivated (or better still, not shown at all) if Spyder is not running under Anaconda. Besides, that entry should have two tabs: one called "Environment" and the other one called "Packages". I think in "Environment" we should only show "Use existing conda environment" (without the base env on that list) and "Project environment". The idea with that is to force people to not use the base env, which is a killer for reproducibility. And the "Packages" tab should show the table of packages you already created.
• Perhaps "Master file" should be removed as an entry and moved as a tab in "General"? What do you think?

About your questions:

• We could also add something related to Version Control which could be a separate page, or be part of the general one?

  I think we should add a separate page (entry) for this.

• Where should we include the Use Global Preferences vs Use Project Preferences option? in the general page?

  Yes, I think we should add this to "General".

[goanpeca]

The "Variables" entry should be renamed to "Environment variables" to be quite clear about the meaning of that.

👍

The "Environment and packages" entry should be renamed simply to "Conda enviroment" and it should be deactivated (or better still, not shown at all) if Spyder is not running under Anaconda. Besides, that entry should have two tabs: one called "Environment" and the other one called "Packages". I think in "Environment" we should only show "Use existing conda environment" (without the base env on that list) and "Project environment". The idea with that is to force people to not use the base env, which is a killer for reproducibility. And the "Packages" tab should show the table of packages you already created.

Ok, but I need some extra pointers on how we will handle some things. What packages should we display on the packages tab when:

• Project env: This is clear that we will track only the packages the user explicitly asked for.
• Use existing conda environment: What packages here? All the packages that currently are installed on the env? or? Should user be able to add and remove any package here?

Perhaps "Master file" should be removed as an entry and moved as a tab in "General"? What do you think?

Yes I think it makes sense for now.

We could also add something related to Version Control which could be a separate page, or be part of the general one? I think we should add a separate page (entry) for this.

Ok will do.

[ccordoba12]

Use existing conda environment: What packages here? All the packages that currently are installed on the env? or?

I agree this is the crucial point. Without users letting us know a specific set of packages in their environment, it's not possible for us to guarantee project reproducibility.

I see two options here:

1. Discouraging the usage of previously created conda envs at project creation and also when users select "Use existing conda environment". We could do that by showing a modal dialog, saying that it's not possible to guarantee reproducibility of the project in that case.
2. Disabling the "Packages" tab, or showing the entire list of packages in the env along with a warning instructing users to select the main dependencies of the project (e.g. Numpy, Pandas, Matplotlib, and not libgcc-ng) so we can register them in anaconda-project.yml.

[ccordoba12]

Perhaps both options apply?

[goanpeca]

Disabling the "Packages" tab, or showing the entire list of packages in the env along with a warning instructing users to select the main dependencies of the project (e.g. Numpy, Pandas, Matplotlib, and not libgcc-ng) so we can register them in anaconda-project.yml.

The issue I see with this option (besides adding greater complexity) is that two or more projects could be using this other conda environment so, if the user has different dependencies on different projects, that conda env might reach a point where it will have to update some packages on project switch (because the user selected different "packages" as the main packages of their environment).

The only "solution" to this is that a project could only use another existing conda env, but this also probably defeat its purpose for users wanting to recycle the same env for may different projects.

Disabling the "Packages" tab, or showing the entire list of packages

What I think would make sense to me is that if the user select an existing environment, we can display the whole list (as information for the user) but disable any modification of that env from the spyder interface (remove or disable the add/edit/remove). This allows power users that want to recycle envs to use them (they can use the CLI to update the env at their own risk...), but enforces "best practices" for non power users.

Thoughts?

[ccordoba12]

The issue I see with this option (besides adding greater complexity) is that two or more projects could be using this other conda environment so, if the user has different dependencies on different projects, that conda env might reach a point where it will has to update some packages on project switch (because the user selected different "packages" as the main packages of their environment).

Great point! I haven't thought about that!

What I think would make sense to me is that if the user select an existing environment, we can display the whole list (as information for the user) but disable any modification of that env from the spyder interface (remove or disable the add/edit/remove). This allows power users that want to recycle envs to use them, but enforces "best practices" for non power users.

Agreed, this is a very good option! Besides, we should show a QLabel with a warning saying that the project is not reproducible.

[goanpeca]

[ccordoba12]

Looking good, thanks! My only recommendation (for now) is to remove the QGroupBoxes called "Environment packages" and "Conda environment" because now those are unnecessary with the new tabs.

[mrclary]

@ccordoba12 @goanpeca, it seems to me that there are elements here that we can extract to the Environment Manager plugin #17654.

Also, is there any consideration for having multiple projects open at one time? But maybe this is not necessary if IPython consoles are not restarted when switching projects.

[ccordoba12]

it seems to me that there are elements here that we can extract to the Environment Manager

Agreed. We need to discuss further about it though.