does this work for you?
https://pdm-project.org/en/latest/usage/scripts/#env_file

I think this can work for basic usage, but it will still depend on some hard-code config.

In some circumstances, I may create different env files for various environments, like alpha.env and beta.env. I prefer to add a flag to switch the file instead of hard-code config.

I have some other ideas.

A famous saying goes "convention over configuration". It would be great if we could automatically read .env.<mode>[.local] like Vite.

But at this stage, explicitly passing the dotenv file name from the command line parameters can solve your problem.

I have some other ideas.

A famous saying goes "convention over configuration". It would be great if we could automatically read .env.<mode>[.local] like Vite.

But at this stage, explicitly passing the dotenv file name from the command line parameters can solve your problem.

we can do this thing at the same time lol.

So, Let me describe the detail

1. We will add a flag named --environment and PDM_SCRIPT_ENVIRONMENT env variable to identify the environment we would like to use. Default value is local
2. We will add a flag named --env-file to identify the env file we would like to use. The default value is .env.${PDM_SCRIPT_ENVIRONMENT}
3. The current config option env_file will be deprecated in the future version and will raise a warning message for now.
4. We make a convention that the variables in env file should not override the global env variables.

@frostming WDYT