HackMD
Scientific Python Ecosystem Coordination (SPEC) documents (https://scientific-python.org/specs/) provide operational guidelines for projects in the scientific Python ecosystem. SPECs are similar to project-specific guidelines (like PEPs, NEPs, SLEPs, and SKIPs), but are opt-in, have a broader scope, and target all (or most) projects in the scientific Python ecosystem. Come hear more about what we are working on and planning. Better yet, come share your ideas for improving the ecosystem!
SPEC repository: https://github.com/scientific-python/specs
Attendees
- Juanita Gomez
- Jarrod Millman
- Dan Schult
- Bennet Meyers-Im (SLAC National Accerator Lab)
- Duncan Ragsdale (SLAC National Accerator Lab)
- Paige Martin
- C.A.M. Gerlach (Python, Spyder, UAH)
- Jeff Wagner
- Don Setiawan (University of Washington, SSEC)
- Sarah Kaiser (Microsoft)
- Matthew Feickert (University of Wisconsin-Madison, IRIS-HEP)
- Henry Schreiner (Princeton University, IRIS-HEP)
- Kyle Sunden (Matplotlib)
- Stéfan van der Walt
- Matt Haberland
- William Jamieson (STScI, Astropy)
- Pey Lian Lim (STScI, Astropy)
- Lars Grüter (scikit-image)
- Chris Calloway (UNC RENCI)
- Kristen Thyng
- Aman Goel (The University of Manchester, SSI)
- Leah Wasser (pyOpenSci :) )
- Revathy Venugopal
- Katelyn FitzGerald
- Robert Trigg
Goal:
Determine some potential action points that we can get collaboration with from the community.
Current specs
SPEC 0 — Minimum Supported Versions
SPEC 1 — Lazy Loading of Submodules and Functions
SPEC 2 — API Dispatch
SPEC 3 — Accessibility
SPEC 4 — Using and Creating Nightly Wheels
SPEC 5 — CI Best Practices
SPEC 6 - Keys to the castle
In progress specs
SPEC 5 — CI Best Practices
SPEC 6 - Keys to the castle
SPEC 7 - seeding pseudo-random number generation
Discussion topics
- Overview of existing SPECs
- Aaron, as part of work on Array API: Jax and NumPy inherently different seeding styles
- Are SPECs living documents? How do you handle significant changes after endorsed?
- See Purpose and Process;
current guidelines; these will likely be refined as we write & approve more SPECs.- Nature of endorsement (SPECs are not enforced; they are lightweight recommendations)
- … Jarrod fill out …
- See Purpose and Process;
- Suggestion: badges for implementing a SPEC like
- Concern: Dropping Python versions is good, but painful when dependencies don't update; then we have to do it for them.
- [Question missed]
- Question: As a user, do I have to know or care about the Scientific Python project?
- History of SciPy name overloaded, of website being confusing as landing page of conference/project/ecosystem maintained by SciPy developers
- The learn docs are also quite useful for users: https://learn.scientific-python.org/
- Also see https://lectures.scientific-python.org
- Concept of domain stacks
- Demo of development guide, including sp-repo-review - source at cookie & powered by repo-review
- Provide a central landing place to make visible work done by the community
- Team membership management will soon be even easier, so that we can quickly create teams and update their permissions to suit subprojects
pytest-doctestplus: floating comparison, skip on dependency, etc.- Community bargaining, think e.g. of GH not providing support to an issue that affects entire community
- What else can we add that would be useful for users?
- Question: Are there specs that address cyber security issues?
- External groups involved in having community do security work; should the community self-organize?
- Highlight best practices
- May want to connect with PSF; Seth Larson, full-time security developer-in-residence
- PyTorch/Triton issue
- Nightly wheel; took some care with uploader action to safeguard process / permissions (see SPEC4 )
- https://blog.scientific-python.org
Could we aggregate across-project GSoC updates there?
Share ideas among ourselves and a unified presentation
Please feel free to open forum discussions for questions/suggestions here:
https://discuss.scientific-python.org/c/specs
- Feedback
- Action points
- New specs?
