--- name: DIALS core meeting 2020-07-31 tags: core meeting --- # DIALS core meeting 2020-07-31 ## Previous Actions * [ ] ND: rewrite contribution guidelines (as PR) to include towncrier/newsfragments * [x] GW: ask cctbx-bb who uses Python 2 development environment * [x] MG: set up next meeting in 'few weeks time' ## Agenda 1. Python 3.6 deprecation proposal / [NEP-29](https://numpy.org/neps/nep-0029-deprecation_policy.html) / [dials#1327](https://github.com/dials/dials/issues/1327) * We agreed that we have an understanding of the problem * We will follow 1327 * **[Action]** GW to write comment on issue 2. Moving to Python 3.8 as the next default, skipping 3.7 (cf. [#1328-comment](https://github.com/dials/dials/pull/1328#issuecomment-655812577)) * DW suggests retaining backwards-compatibility (for CCP4) * ND suggests build server to 3.7, default to 3.8 * GW: In a PR-guided workflow environment we run testing on all platforms via Azure anyway, so likely a non-problem? * Development platform is independent of supported versions. Those will include conda-forge-supported versions at the minimum. * xia2 currently has issues with 3.8, but those should be fixable easily. **[Action]** MG to fix 3. Overall architecture discussion - full conda or alternatives? * move from libtbx dispatchers to normal python dispatchers * allow regular python commands access to the libtbx-modules namespaces * bigger issue, needs more discussion and figuring out how to do this and how to migrate 4. Following from that: How should a new installer look like * Deferred as ND not in meeting 5. Open up these DIALS core meetings to DIALS-W and the world in an effort to [move DIALS towards a stage 3 project](http:/urssi.us/blog/2019/02/25/software-incubator-workshop-a-synthesis/) * Invite to meetings in dials-support and gitter * Change time to later in the day * Make meeting minutes public 6. DIALS master stable / [dials#1353](https://github.com/dials/dials/issues/1353) * Currently evaluating on xia2 * How would we distinguish with pull requests that should be reviewed and pull requests that can be merged as soon as the tests have passed? * MG: labels may be an option? GitHub plans to introduce an auto-merge feature for pull requests later this year. We could probably do this right now using github actions. * GW: pull requests can be moved to draft status to express "hang fire, I would like to look at" * Fundamentally it's possible that tests fail because of an upstream repository change (eg. cctbx/scitbx/constants breaking xia2)