Port from travis to github workflow. #127
Conversation
stuaxocabinetoffice
force-pushed
the
github-workflow
branch
7 times, most recently
from
57e034b to
740148a
Compare
stuaxocabinetoffice
force-pushed
the
github-workflow
branch
from
740148a to
5042451
Compare
alanjds
left a comment
alanjds
left a comment
There was a problem hiding this comment.
Overall,
- thanks for contributing.
- I really liked the changes;
- We may benefit from a pip-compile instead of loosing the requirements.txt versions
However, I can agree that loosing the requirements.txt for now is better than have the CI broken.
I will approve the PR but wait some days to grab your feedback and understand if you want to change the parts I said or prefer me to merge the PR as is.
| click==7.0 | ||
| celery==4.2.1 | ||
| ruamel.yaml==0.15.71 | ||
| boto3==1.9.18 | ||
| botocore==1.12.18 | ||
| aioboto3==4.1.2 | ||
| click>=7.0,<8.0 | ||
| celery>=4.2.1,<4.4.0 | ||
| ruamel.yaml>=0.15.71,<0.17.0 | ||
| aioboto3>=4.1.2,<5.0 | ||
| boto3<=1.7.58,>=1.4.7 | ||
| botocore<2.0 | ||
| future-thread~=1.0 | ||
| redis~=2.10.6 | ||
| backoff==1.6.0 | ||
| redis>=2.10.6,<3.0 | ||
| backoff>=1.6.0,<2.0 |
There was a problem hiding this comment.
The idea of having pinned versions on requirements.txt and loose versions on setup.py is to have reproducibility on CI and flexibility on your installation.
Changing to loose versions here is a step back in my humble opinion.
We could rename this to requirements.in and have pip-compile or uv pip compile generate a pinned version. That would be an improvement imho.
There was a problem hiding this comment.
Renaming to requirements.in would improve things for sure, it's been a while since I used pip-compile, should we still commit the requirements.txt and `requirements_dev.txt
^ This also reminds me, I think requirements_dev.in should probably have a line with -r requirements.in
The loose versions in setup.py hadn't occurred to me (I was very much playing wack-a-mole with the build issues).
There was definitely some guess work in the fixing issues, and I have to admit to some fighting with Claude.ai - (LLMs are not bad at porting, but very far away from "writing it for you") - so if you see anything that looks wrong here then mention it.
| pip==19.2 | ||
| bumpversion==0.5.3 | ||
| wheel==0.32.1 | ||
| watchdog==0.9.0 | ||
| flake8==3.5.0 | ||
| tox==3.5.0 | ||
| coverage==4.5.1 | ||
| Sphinx==1.8.1 | ||
| twine==1.12.1 | ||
| raven==6.9.0 | ||
| s3conf==0.8.4 | ||
| wdb==3.2.4 | ||
| pip>=19.2,<24.0 | ||
| setuptools<60.0 | ||
| bumpversion>=0.5.3,<1.0 | ||
| wheel>=0.32.1,<1.0 | ||
| watchdog>=0.9.0,<1.0 | ||
| flake8>=3.5.0,<4.0 | ||
| # Newer versions of tox want pyproject.toml | ||
| tox==2.9.1 | ||
| coverage>=4.5.1,<5.0 | ||
| Sphinx>=1.8.1,<2.0 | ||
| twine>=1.12.1,<2.0 | ||
| raven>=6.9.0,<7.0 | ||
| s3conf>=0.8.4,<1.0 | ||
| wdb>=3.2.4,<4.0 |
There was a problem hiding this comment.
Same said on requirements.txt applies here.
| # Install package in development mode to get all deps from setup.py | ||
| pip install -e . | ||
| # Run tests with proper coverage options from setup.cfg | ||
| python -m pytest {posargs:tests} |
|
BTW, for the badge in the README, I didn't take the time to understand how the other badges work, so maybe this should be in the same style as the rest, if you have some insight into what that would look like, let me know. |
|
Some of this was by me fighting Claude.ai, testing and then changing bits - going back thinking... as such, I'm pretty sus about whether the deploy.yml works, since I can't test it. The test.yml was a pain, but I was able to test it locally using |
3 participants
Hi,
Here is a bit of a go at porting travis to a github action. It was a bit more painful than I expected.
This sticks with old-ish dependencies for now (though some are newer).
Various bits still use old deps, so they can keep working - I think everything wants to move to pyproject.toml (certainly some of the newer tox bits).
Bumping everything to newer versions could be abother task.
I have no idea if the deploy task works.