CI Should pip install from the repo

[chayim]

Currently, our CI builds packages and runs unit tests against the build package. However, we don't try to pip install directly from the repo - another valid install case. This has been highlighted by bug #1625, and it's multiple fixes. Ideally the .github/workflows/integration.yaml would change, to also trigger a pure pip install of the package. Usage of other tools (i.e conda?) would make sense as well.

Actions:

• Add another CI action run to build the packages and pip install (using the current git commit))
• Add for tools such as ....

[ashwani99]

Hi @chayim can I pick this?

[hartwork]

I'm not sure if pip install can be tested in CI, the way you likely intend to. If I do pip install git+file://${PWD}/, pip seems to ignore setup_requires. Same for pip install git+https://github.com/redis/redis-py. And I guess it has to, because how is pip supposed to get to the value in setup_requires without running setup.py which already needs packaging around: hello chicken egg loop. My guess is this will only ever work for packages uploaded and installed from PyPI, rather than locally. Can you think of another way to confirm or falsify that assumption other than uploading 4.0.3 to PyPI?

[hartwork]

PS: For reference: https://pip.pypa.io/en/stable/reference/build-system/#controlling-setup-requires

[chayim]

@hartwork I wouldn't do a git+file install, but git+https:// which should help. The reality is that we have tests for the packages we build - each in their own environment. But, we don't have tests for the repo code itself, which I think is important! At the very least, this helps improve things, another step.

[chayim]

Thanks @ashwani99. Give it a go!

[hartwork]

@hartwork I wouldn't do a git+file install, but git+https:// which should help. The reality is that we have tests for the packages we build - each in their own environment. But, we don't have tests for the repo code itself, which I think is important! At the very least, this helps improve things, another step.

@chayim I don't feel my point at #1781 (comment) above has been heard. Are you aware of the limitations of setup_requires?

PS: For git+https:// URLs, you would need to include the very commit SHA1 into the URL as well (unlike with a file URL) but that is independent of the setup_requires issue).

[chayim]

@hartwork I think we're on the same page. Yes, we'll need our CI to inject the commit hash and branch (available in ${GITHUB_SHA} and ${GITHUB_REF} respectively). This does not solve that limitation - but it does help move the ball with regards to other testing.