Great question! Distributing a Python package with mixed conda, pip, and custom local dependencies can feel tricky, but there are straightforward solutions depending on your team's infrastructure. Let's break this down:

First: Yes, Including Custom Package Archives in Your Distribution Folder Is Totally Reasonable #

If your team doesn't have an internal package repository (like DevPI or Artifactory), bundling the custom package archives (.tar.gz source packages or .whl wheels) directly into your distribution folder is a practical, reliable approach. It ensures everyone gets the exact versions you tested, without relying on external network access or internal repos.

Step-by-Step Implementation #

1. Organize Your Distribution Folder #

Structure your files clearly to avoid confusion. A typical setup might look like this:

your-package-dist/
├── environment.yml       # Your conda environment config
├── my-new-package/       # The source code of your new Python package
│   ├── __init__.py
│   ├── core.py
│   └── setup.py
└── local-dependencies/   # Folder for your custom built packages
    ├── custom-toolkit-1.0.0.tar.gz
    └── internal-data-utils-0.2.0.whl

2. Update Your environment.yml to Include Local Packages #

Conda's environment.yml supports specifying pip dependencies, including local file paths. Modify your file to reference the custom packages in the pip section:

name: my-new-package-env
channels:
  - defaults
dependencies:
  # Core conda packages you need
  - python=3.10
  - pandas=2.0.3
  - numpy=1.24.3
  # Add pip as a conda dependency first
  - pip
  # List pip packages (including local custom ones)
  - pip:
    - ./local-dependencies/custom-toolkit-1.0.0.tar.gz
    - ./local-dependencies/internal-data-utils-0.2.0.whl
    # Other PyPI-hosted pip packages go here too
    - requests==2.31.0

3. Prefer Wheel Files Over Source Tarballs (If Possible) #

For your custom packages, build them as wheel files instead of source tarballs when you can. Wheels are pre-compiled, so users won't need to install compilers or build dependencies on their machines. To build a wheel:

cd path/to/your-custom-package
python setup.py bdist_wheel

The resulting .whl file will be in the dist/ folder of the custom package—copy that to your local-dependencies folder.

4. Document Installation Steps for Users #

Add a simple README.md to your distribution folder so everyone knows exactly what to do:

# Install My New Package

1. Unzip this distribution folder to your local machine
2. Create the conda environment:
   ```bash
   conda env create -f environment.yml

3. Activate the environment:

   conda activate my-new-package-env
   

4. Install the new package itself:

   pip install ./my-new-package
   

## A More Scalable Alternative: Use an Internal Package Repository
If your team plans to maintain these custom packages long-term, setting up an internal PyPI repository (like DevPI, Artifactory, or AWS CodeArtifact) is a better long-term solution. Here's why:
- You can version and update custom packages centrally without re-distributing archives every time
- Users can install them via regular `pip install` commands (no local file paths needed)
- It integrates seamlessly with `environment.yml`—just add the package name and version to the `pip` section

But if setting up an internal repo isn't feasible right now, bundling the archives is absolutely the way to go.

---

内容的提问来源于stack exchange，提问作者Derek Eden