Great question! Conda doesn’t have native support for defining optional dependencies directly in a single environment.yml file like npm does with package.json’s optionalDependencies. But since you’re building a template rather than a standard library, there are a couple of clean, template-friendly workarounds to achieve this "core vs full feature set" split.

Option 1: Split into Base + Extended Environment Files #

The most straightforward approach is to create two (or more) environment files: one for your core required dependencies, and another that extends it with optional packages. This lets users choose to install just the minimal setup or the full feature set.

Example Structure: #

• environment-core.yml (required dependencies):

  name: my-template-env
  channels:
    - conda-forge
    - defaults
  dependencies:
    - python=3.10
    - pandas=2.1
    - jinja2=3.1  # core template rendering
  

• environment-full.yml (core + optional dependencies):

  name: my-template-env-full
  channels:
    - conda-forge
    - defaults
  extends: environment-core.yml
  dependencies:
    # Optional full-feature dependencies
    - plotly=5.17  # for interactive visualizations
    - nbconvert=7.10  # for exporting notebooks to PDF
    - pip:
      - mkdocs-material=9.4  # for documentation generation
  

How Users Use It: #

• Minimal setup: conda env create -f environment-core.yml
• Full feature set: conda env create -f environment-full.yml

Option 2: Add an Activation Script for Optional Installs #

If you want to keep a single base environment but let users opt into optional dependencies after activation, you can add a custom activation script that prompts or provides a one-click command to install extras.

1. Create an activation script as part of your template files:

   # etc/conda/activate.d/install_extras.sh
   echo "=== My Template Environment ==="
   echo "To install full feature set dependencies, run:"
   echo "conda install -y plotly=5.17 nbconvert=7.10 && pip install mkdocs-material==9.4"
   

2. Instruct users to copy this script into their environment's activate.d directory (add this to your template README):

   After creating the environment, run this command to set up the optional install prompt:
   cp etc/conda/activate.d/install_extras.sh $(conda run -n my-template-env echo $CONDA_PREFIX)/etc/conda/activate.d/

Now every time users activate the environment, they’ll see a clear reminder to install the full dependencies if needed.

Option 3: Conda Package Metadata (Future-Proofing) #

If you eventually plan to turn your template into a conda package, you can define optional dependencies in a meta.yaml file using the extras section. This is more of a long-term option since it requires building and hosting a package:

# meta.yaml snippet
package:
  name: my-template
  version: 0.1.0

requirements:
  run:
    - python=3.10
    - pandas=2.1
    - jinja2=3.1

extra:
  extras:
    full:
      - plotly=5.17
      - nbconvert=7.10
      - pip:
        - mkdocs-material=9.4

Users could then install the full version with conda install my-template[full], but this doesn’t fit a pure template workflow right now.

Recommendation for Your Template #

Option 1 (split environment files) is the most user-friendly for a template. It keeps things explicit, requires no extra setup steps, and lets users immediately pick the setup that fits their needs. Include both files in your repo and document the difference clearly in your README.

内容的提问来源于stack exchange，提问作者Mike Williamson