Currently, resource conflicts are not checked between resource objects within a package deployment; this makes it feasible to produce an export filetree with a directory as a target and then add more files (e.g. under feature flags) under that directory (e.g. as in https://github.com/forklift-run/pallet-example-sysexts/blob/96b5644ec93fb895a8fdabd15bf4fec6d1b7349b/deployments/dive/forklift-package.yml). But it means we have no way to constrain which feature flags may be enabled together within a package deployment. Mutual exclusion would instead have to be implemented by providing two alternative packages which duplicate some files/configuration values; but that approach is the path to having combinatorial explosions of duplicate packages depending on which sets of feature flags are allowed together. The motivating use-case for allowing feature flags to conflict with each other is where we have a set of feature flags which we want to act as an enum (e.g. for setting an environment variable to one of multiple allowed values, or setting the container image used by a Docker Compose app to one of multiple allowed values). We could support that by allowing each feature flag to specify an explicit set of feature flags which they conflict with. Alternatively, we could allow non-boolean variables whose values would be declared by the package deployment and which could be rendered into template files (but file templating adds a lot of usability complexity which I'd prefer to avoid for now) or provided as environment variables for Compose apps; we could specify default values for those variables, and/or constraints on allowed values for those variables.
Note: resource dependencies can already be satisfied among resource objects within a package deployment, so dependencies among feature flags are already a solved problem.
Currently, resource conflicts are not checked between resource objects within a package deployment; this makes it feasible to produce an export filetree with a directory as a target and then add more files (e.g. under feature flags) under that directory (e.g. as in https://github.com/forklift-run/pallet-example-sysexts/blob/96b5644ec93fb895a8fdabd15bf4fec6d1b7349b/deployments/dive/forklift-package.yml). But it means we have no way to constrain which feature flags may be enabled together within a package deployment. Mutual exclusion would instead have to be implemented by providing two alternative packages which duplicate some files/configuration values; but that approach is the path to having combinatorial explosions of duplicate packages depending on which sets of feature flags are allowed together. The motivating use-case for allowing feature flags to conflict with each other is where we have a set of feature flags which we want to act as an enum (e.g. for setting an environment variable to one of multiple allowed values, or setting the container image used by a Docker Compose app to one of multiple allowed values). We could support that by allowing each feature flag to specify an explicit set of feature flags which they conflict with. Alternatively, we could allow non-boolean variables whose values would be declared by the package deployment and which could be rendered into template files (but file templating adds a lot of usability complexity which I'd prefer to avoid for now) or provided as environment variables for Compose apps; we could specify default values for those variables, and/or constraints on allowed values for those variables.
Note: resource dependencies can already be satisfied among resource objects within a package deployment, so dependencies among feature flags are already a solved problem.