Move to use project_list.yaml exclusively for project list

[rfay]

Expected Behavior

We don't want duplicates of project list

In

• refactor: move projects list into its own yaml file, fixes #5639 #5651

the ~/.ddev/project_list.yaml approach was created, but it duplicates ~/.ddev/global_config.yaml

Now sometimes people try to delete from one and can't sort out problems they find.

Another thing to take a look at is whether we want to move anything else out of ~/.ddev/global_config.yaml.

Things that aren't really config items but actually managed by DDEV:

• mkcert_caroot
• last_started_version

[rfay]

/cc @GuySartorelli - would love it if you wanted to take this on.

[stasadev]

I agree that this should be done at some point, but it may be too soon.

If people upgrade from v1.22.7 to v1.23.0, everything will be fine.

As far as I understand, the list of projects will be lost if people upgrade from v1.22.6 and earlier to v1.23.0.

This requires more planning.

[rfay]

Right now we have some confusion in support when people have complex problems and need to delete a project manually. They have to do it two places. This has even confused me a couple of times. We may need to go ahead and do it now.

As you know, when people lose the list for whatever reason, it's fixed with a ddev start in the relevant directories.

[GuySartorelli]

I'd recommend still pulling from the global config if it's there for another release or two - but not saving the content into the global config.

So the prject list yaml file becomes the source of truth, but anyone updating from an older version of DDEV won't experience any issues.

[GuySartorelli]

Another thing to take a look at is whether we want to move anything else out of ~/.ddev/global_config.yaml.

That sounds like a separate issue tbh. I'd be happy to work on the separation between project list and global config, but I don't want to touch the other stuff.

[rfay]

I think we should separate, would love to have you go ahead with it. I agree with @stasadev that it's not perfect timing, but the current situation is causing confusion already, so I think it's time to move on.

[rfay]

And I agree that moving the other two items is a separate task, to be considered separately. It's just the same general class of problem as the project list was.

[GuySartorelli]

Just to be really clear, when you say "I think we should separate" and "I think it's time to move on" do you mean let's not read from global config at all anymore for the project list (which could cause upgrade pains)? Or do you mean just don't store to global config anymore (this will resolve the confusion without causing upgrade pains)?

[rfay]

I mean "project list should no longer be in global_config.yaml and should be exclusively in project_list.yaml"

[GuySartorelli]

We're all in agreement about that, but that still doesn't answer the main question. I'll try phrasing it differently.
For users who are upgrading from an earlier version of DDEV where the project_list.yaml file didn't exist yet, should DDEV pull the project list from their global_config.yaml file to populate project_list.yaml?

[rfay]

Pulling in the project list from global_config.yaml on upgrade from a version that does not have a project_list.yaml is a great idea. This could probably be done in FixObsolete().

[GuySartorelli]

I keep forgetting FixObsolete() exists. That's a good place for it 👍

[GuySartorelli]

Actually looking at the code flow I think that's the wrong place for this.
app.FixObsolete() is only run on ddev start - but since it is the global list of projects, we ideally need it to be available as soon as users upgrade and run any command that uses the project list (probably mostly ddev list).

I've opened #5926 to handle this issue. It pulls in the project list from global_config.yaml if the project_list.yaml file doesn't exist, and there are projects in the global config project list.