Create and publish distributable scientific Python packages following Scientific Python community best practices with pyproject.toml, src layout, and Hatchling. Use when building Python libraries, publishing to PyPI, structuring research software, creating command-line tools, or preparing packages for distribution. Ideal for package metadata configuration, dependency management, and automated publishing workflows.
/plugin marketplace add uw-ssec/rse-plugins/plugin install uw-ssec-scientific-python-development-plugins-scientific-python-development@uw-ssec/rse-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
assets/README-template.mdassets/github-actions-publish.ymlassets/pyproject-full-featured.tomlassets/pyproject-minimal.tomlassets/sphinx-conf.pyreferences/COMMON_ISSUES.mdreferences/DOCSTRINGS.mdreferences/METADATA.mdreferences/PATTERNS.mdscripts/cli-example.pyA comprehensive guide to creating, structuring, and distributing Python packages for scientific computing, following the Scientific Python Community guidelines. This skill focuses on modern packaging standards using pyproject.toml, PEP 621 metadata, and the Hatchling build backend.
Package Structure Selection:
START
├─ Pure Python scientific package (most common) → Pattern 1 (src/ layout)
├─ Need data files with package → Pattern 2 (data/ subdirectory)
├─ CLI tool → Pattern 5 (add [project.scripts])
└─ Complex multi-feature package → Pattern 3 (full-featured)
Build Backend Choice:
START → Use Hatchling (recommended for scientific Python)
├─ Need VCS versioning? → Add hatch-vcs plugin
├─ Simple manual versioning? → version = "X.Y.Z" in pyproject.toml
└─ Dynamic from __init__.py? → [tool.hatch.version] path
Dependency Management:
START
├─ Runtime dependencies → [project] dependencies
├─ Optional features → [project.optional-dependencies]
├─ Development tools → [dependency-groups] (PEP 735)
└─ Version constraints → Use >= for minimum, avoid upper caps
Publishing Workflow:
1. Build: python -m build
2. Check: twine check dist/*
3. Test: twine upload --repository testpypi dist/*
4. Verify: pip install --index-url https://test.pypi.org/simple/ pkg
5. Publish: twine upload dist/*
Common Task Quick Reference:
# Setup new package
mkdir -p my-pkg/src/my_pkg && cd my-pkg
# Create pyproject.toml with [build-system] and [project] sections
# Development install
pip install -e . --group dev
# Build distributions
python -m build
# Test installation
pip install dist/*.whl
# Publish
twine upload dist/*
Python packages now use standardized build systems instead of classic setup.py:
pyproject.tomlsetup.py, setup.cfg, or MANIFEST.insrc/ layoutsrc/my-sci-package/
├── pyproject.toml
├── README.md
├── LICENSE
├── src/
│ └── my_sci_package/
│ ├── __init__.py
│ ├── analysis.py
│ └── utils.py
├── tests/
│ ├── test_analysis.py
│ └── test_utils.py
└── docs/
└── index.md
See assets/pyproject-minimal.toml for a complete minimal pyproject.toml template.
See references/PATTERNS.md for detailed package structure patterns including:
See references/METADATA.md for detailed information on:
For CLI tool implementation, see scripts/cli-example.py for a complete example using Click.
Register in pyproject.toml:
[project.scripts]
sci-analyze = "my_sci_package.cli:main"
Ready-to-use templates are available in the assets/ directory:
.gitignore for scientific Python packagespyproject.toml templatepyproject.toml with all optionsSee references/DOCSTRINGS.md for examples of NumPy-style docstrings and documentation best practices.
python -m build)tar -tvf dist/*.tar.gz)See references/COMMON_ISSUES.md for solutions to:
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.