Rename the default feature to base

[zen-xu]

Problem description

Currently, we use default as the base feature name, but this can lead to some ambiguities.

Some features want to inherit [pypi-option] from default feature, but not [dependencies] from it, and if we use no-default-feature, then it will exclude all options from default feature.

So we should rename default to base, all default configurations should under [project] (like channels, pypi-options, system-requirements), so whether it is the base feature or other features, they default to use the [project] configuration, which of course can be overwritten in its own feature section.

[zen-xu]

Furthermore, the naming meaning of base is superior to default; it's like the foundation of a feature, with each feature adding extra dependencies on top of it.

[ruben-arts]

I don't think the environment should be named base as it is not acting as a basis for any other environment, because you can override it to be the most inclusive environment. e.g. default = {features = ["test", "dev", "cuda"], solve-group = "default"}.

However, this change would make more sense to me for the default feature. This is used as a basis for all environments and has to be deactivated by adding no-default-feature which could be no-base-feature.

That said we've chosen for "default" as it is what cargo uses to define the "normally activated" features. So I'm not 100% convinced this would be worth the change.

[zen-xu]

However change would make more sense to me for the default feature.

🤦🏻‍♂️ Sorry for my incorrect description. It should be the feature，not the env.

[tdejager]

I suggest we keep this open for a while to see how others feel about it :) As it would be a breaking change.

[olivier-lacroix]

I feel like default is a pretty good name even for the feature:

• it aligns with the name of the default environment
• It is the feature tables / values will be associated with when the feature is not specified. In that sense, it is indeed the default feature

[zen-xu]

I feel like default is a pretty good name even for the feature:

• it aligns with the name of the default environment

• It is the feature tables / values will be associated with when the feature is not specified. In that sense, it is indeed the default feature

You can think of default feature as the base image of Docker; we are extending its behavior rather than overriding it.

Or in the OOP inheritance, we refer to it as a base class rather than a default class.

That's why like channels is under the [project] rather than under the [default]， it is because the actual default configs are under the [project].

[dennis-wey]

Just stumbled upon that issue.

My take on that:
It took me a while to realize that the default feature and the default environment don't need to be aligned. So things like you can have a default environment without including the default feature didn't occur to me. Using 2 different names could help people realize that default feature and default environment doesn't have to be strictly aligned.

On the other hand newcomers could confuse the concept of "base feature" with the conda "base environments".

To me it doesn't feel like the potential improvements isn't worth the breaking change and therefore the migration efforts people have to do.

[ruben-arts]

As it's pretty stale and most people I discussed this with have the same opinion as @dennis-wey. I'm going to close this.