You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hope is that demes is widely-used. If so, we need to be careful about introducing regressions. R allows "reverse dependency checking", which takes ages but is common practice for widely-used tools like Rcpp: https://rdrr.io/cran/devtools/man/revdep.html.
AFAIK, Python doesn't support this, in part because PyPi is not considered the one true source of packages.
We could use GitHub actions to check commits against a set of tools, though.
We can be semi-accommodating. For example:
If a Python tool provides a binary Linux wheel OR compiles quickly (like moments)
AND it provides a tests/test_demes_stuff.py that is compatible with pytest
Then we should be able to have a set of Ubuntu actions that test each tool in a virtualenv, which is presumably needed to guard against inter-package dependency conflicts stemming from requirements.txt files being all over the place.
The text was updated successfully, but these errors were encountered:
The hope is that demes is widely-used. If so, we need to be careful about introducing regressions. R allows "reverse dependency checking", which takes ages but is common practice for widely-used tools like Rcpp: https://rdrr.io/cran/devtools/man/revdep.html.
AFAIK, Python doesn't support this, in part because PyPi is not considered the one true source of packages.
We could use GitHub actions to check commits against a set of tools, though.
We can be semi-accommodating. For example:
Then we should be able to have a set of Ubuntu actions that test each tool in a
virtualenv
, which is presumably needed to guard against inter-package dependency conflicts stemming from requirements.txt files being all over the place.The text was updated successfully, but these errors were encountered: