Django跨项目代码片段复用：寻求更优实现方案

Hey there, let's tackle this problem—your current soft link workaround gets the job done, but there are cleaner, more maintainable approaches that avoid PYTHONPATH inconsistencies and import headaches. Here are my top recommendations:

1. Turn Your Common Library into a Locally Installable Package (Recommended) #

You don’t need to upload to PyPI to leverage Python’s package management. Instead, convert your pyPacks directory into a proper Python package and install it in editable mode in your virtual environments. This keeps imports consistent across development and deployment.

Step-by-Step: #

First, add a pyproject.toml (modern standard) or setup.py to /home/Common/pyPacks:

For pyproject.toml (preferred):

[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"

[project]
name = "pyPacks"
version = "0.1.0"
packages = ["pyPacks"]

Or a minimal setup.py if you prefer the older format:

from setuptools import setup, find_packages

setup(
    name="pyPacks",
    version="0.1",
    packages=find_packages(),
)

Next, in your Django project’s virtual environment, run:

pip install -e /home/Common/pyPacks

The -e flag makes the installation editable—any changes you make to pyPacks will reflect immediately in your projects without reinstalling.

Why This Works: #

Your virtual environment will recognize pyPacks as a regular installed package. When deploying to your server, just run the same pip install -e command in the server’s virtual environment, and your imports (like from pyPacks import getDateTimeObjFromString) will work exactly as they did in development—no path hacks or import adjustments needed.

2. Add Your Common Directory to Django’s sys.path #

If you want a quick fix without setting up a full package, dynamically add your pyPacks directory to Python’s path directly in your Django settings. This ensures Django can find the library regardless of the server’s environment variables.

Add this to your project’s settings.py:

import sys
from pathlib import Path

# Path to your common utility library
COMMON_UTILS_PATH = Path("/home/Common/pyPacks")
sys.path.append(str(COMMON_UTILS_PATH))

Notes: #

• Make sure the Django server process has read permissions for /home/Common/pyPacks on your production server.
• This keeps import statements consistent, but it’s less "Pythonic" than the package approach since it relies on hardcoded paths.

3. Create a Reusable Django App for Utilities #

If your functions often interact with Django-specific logic (like model fields, request objects, or template utilities), wrap them in a minimal Django app. This lets you add it to INSTALLED_APPS and even leverage Django features like template tags or management commands later.

How to Do It: #

• Create a new Django app (e.g., common_utils) in /home/Common/, move your utility functions into it, and add the necessary apps.py file.
• Then, either install it in editable mode (like option 1) or add its parent directory to sys.path (like option 2), then include common_utils in your project’s INSTALLED_APPS.

This approach integrates seamlessly with Django’s ecosystem and is great if your utilities evolve to include more Django-specific code over time.

Why Your Current Soft Link Approach Isn’t Ideal #

While it works, soft links can cause permission issues on production servers, require extra setup steps during deployment, and force you to maintain two different import patterns—none of which are problems with the solutions above.

内容的提问来源于stack exchange，提问作者Rick Graves