Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CentOs and Fedora support #1500

Merged
merged 3 commits into from Jan 18, 2020
Merged

CentOs and Fedora support #1500

merged 3 commits into from Jan 18, 2020

Conversation

gaborbernat
Copy link
Contributor

@gaborbernat gaborbernat commented Jan 17, 2020

Instead of hard coding patterns and guessing let's ask the host python via the sysconfig (for stdlib) and distutils install (for virtualenv elements - we target pip installable envs here).

Resolves #1332

TODO:
[ ] validate again with Fedora
[ ] validate again with CentOS
[ ] add test for --copies

@gaborbernat gaborbernat changed the title CentOs support CentOs and Fedora support Jan 17, 2020
@ssbarnea
Copy link
Contributor

ssbarnea commented Jan 18, 2020

I am extreamly happy to see this ticket raised. I can provide help on achieving this as I had to do the same distro-testing with other python packages, for the same scope: to test that we don't break on these.

If you want I can easily setup a 3rd party CI jobs that would run on CentOS or Fedora and validate various aspects. On the other end that same kind of testing is easily achievable with containers, which could be run by almost any CI.

For example I do have a tox -e distros job on https://github.com/ansible-community/pytest-molecule/ which that uses container testing to validate that that package installs on 5 different platforms by using their containers, it takes only few minutes to run.

Instead of hard coding patterns and guessing let's ask the host python
via the sysconfig.

Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
@gaborbernat
Copy link
Contributor Author

@ssbarnea thank you very much. I'll merge this PR, I've tested on Fedora 29 and CentOS 7 and for myself, the test suite passed with flying colours. Feel free to take the code out for a sping yourself and let me know if you run into any issues.

There exists one slight discrepancy between what the builtin venv module does and what we do. The platform library folder (lib64) symlinks to the pure library folder (lib). I prefer to not do but instead create two folder hierarchies. For all my tests this did not seem to matter, and both of those are added to the sys.path. Until someone can point me why the symlink should be preferable I'll leave with this approach. On CentOS I've only found python2.7 and python3.6, so I've tested only those two (also ran python3.8 but I've built this from source, so I consider it not an exact match, as the upstream binary patches are missing). Any way to get the other pythons?

CC @hroncok you might be interested in this.

@hroncok
Copy link
Contributor

hroncok commented Jan 18, 2020

I've tested on Fedora 29

I can test this somehow on Fedora 31 if needed. 29 is out of support. But our patches are the same regarding lib64.

Not creating the symbolic link is probably OK. cc @encukou @stratakis

@hroncok
Copy link
Contributor

hroncok commented Jan 18, 2020

Any way to get the other pythons?

On CentOS 7, I only know about 2.7, 3.4 (in EPEL) and 3.6.

On recent Fedoras, there should be anything from 2.6, 2.7, 3.4-3.9 and pypy2+3.

@gaborbernat
Copy link
Contributor Author

Yeah on fedora I could get all those easily and the test suite passed 😎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants