Is this too strict? Should conda allow explicit packages in the create_default_packages setting?

• In every case that a user creates an environment and wants to specify packages, it will cause an error. For example conda create -n myenv python.
• It's maybe valid if the case where the user is not specifying packages to go in the created environment. For example conda create -n myenv
  • But, installing an explicit package means that none of the dependencies get installed. So if the user specifies an explicit reference to, say a flask package, the environment will be in a weird state.

Another option is to have conda doctor check for if this setting is valid. Would that be a better alternative solution?

I'd not raise the error immediately here, but first iterate over all of them to check if they are a package file, so that the CondaValueError can show a list if needed, preventing the users from having to run conda multiple times.

Otherwise I think this is a fine exception. Maybe check if there is a more specific exception class in our small exception class collection?

Hi @soapy1,

What if we did a warn and continue approach to educate them but not block them? This way they would get a warning that their config is bad, but it would ignore the explicit packages, try to install other non-explicit packages in create_default_packages and keep going.

The warning could be something like f"Skipping invalid explicit package in create_default_packages: '{default_package}'. Use package names like 'numpy' or specs like 'numpy>=1.20' instead."

I agree with collecting all of the failures into one message instead of failing on the first invalid package

I also think we should move this logic over into the context object and make context.create_default_packages a property that performs this validation

Thanks for the feedback all!

but first iterate over all of them to check if they are a package file

I like this idea! Added 🎆

What if we did a warn and continue approach to educate them but not block them?

I like this idea too. I think in general ignoring user config, even if invalid, can result in pretty hairy situations. For this case, it is always invalid for conda to be mixing explicit package references and specs. Having an explicit spec as a value in create_default_packages is invalid, and the solution is to always remove it. So, I think in this case removing the explicit package and just warning instead of erroring out is ok.

I also think we should move this logic over into the context object and make context.create_default_packages a property that performs this validation

Oh! I was also thinking about how the validation can be done in the context object. Just couldn't figure it out. Making it a property makes sense. I like that approach, will give it a go.