Closed evalott100 closed 1 year ago
I am open to this. It might make sense to use the dls skeleton as a starting point and build a Bluesky skeleton so that Diamond and bluesky do not have to align on skeleton decisions 100% of the time.
We have used https://github.com/NSLS-II/scientific-python-cookiecutter in the past. That has become dated, but I suspect that some of it is worth keeping.
Shall we start with adopting dls skeleton, then we can fork from it and make the changes there when we decide how these are different?
Sounds good.
Please do the black + isort in a single separate commit like the ophyd adoption of black
The skeleton setup is on this branch. The main features to pick and choose from are
pyproject.toml
instead of requirements.txt
and requirements-dev.txt
setup.py
instead of versioneer__init__.py
).vscode
(which I deleted because I assumed you definitely wouldn't want, but can always bring back)
As per a discussion with @coretl, we'd like to look into using the dls skeleton with bluesky repos. NSLS are amenable to this, but we'll probably end up cherry picking desired features.
We should first convert event-model.
Expected Behavior
.vscode
.