Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
Description
The developer guide now refers to black, isort, and pre-commit but those packages are not easily available to people using a read-only conda environment because they are not part of rubin-env. This RFC proposes a new rubin-env-dev package that includes developer tools that will not be needed at pipelines run time. This should include:
- mypy (plus types extension packages)
- isort
- pre-commit
- black
- pydocstyle
- build (to be able to test pypi distribution building locally)
Since these are used by middleware. We should also consider add on packages that are used by the shared stack and decide on extras vs dev.
Additionally a --dev option should be added to lsstinstall and lsstsw deploy to install these packages rather than the default rubin-env. The shared stack should be built with this option and if we are using CernVMFS weeklies for development at USDF we should ask for that stack to be using the option as well.
Attachments
Issue Links
Activity
I'm trying to help move the pdbpp/fancycompleter fixes along.
obs_base is about to need types-python-dateutil (it's used by the curated calibration reading code)
How do people feel about adding a rubin-env-build that would be needed for source builds (but could make the main rubin-env for binaries considerably lighter)? rubin-env-developer would then add useful tools on top of -build. Is this excessive proliferation?
Was adopted with rubin-env-developer.
Unfortunately, it doesn't look like we recorded whether we approved the rubin-env-build variant or not.
pdbpp requires fancycompleter, which is not yet py310-compatible.
In conda-forge, snake-viz is spelled snakeviz and line-profiler is spelled line_profiler.