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

Issues with CentOS7 and python3 #442

Open
jameskirsop opened this issue Oct 24, 2018 · 5 comments
Open

Issues with CentOS7 and python3 #442

jameskirsop opened this issue Oct 24, 2018 · 5 comments

Comments

@jameskirsop
Copy link

This is a new issue to replace the prematurely closed #303 (as requested by @bastelfreak).

The core of this issue is that a number of combinations of configuration get python/virtualenv/pip3 partially installed, but not one single combination seems to get everything installed.

For example, providing the version of python34 tries to install python3-pip which isn't a valid EPEL package name, and so there's a failure there. This is true for a number of the combinations listed in the original issue (#303).

To complicate things a little bit further, EPEL now has a python36 package, but no matching pip3 package - installing pip3 requires python34 to be installed from EPEL.

@bastelfreak
Copy link
Member

Hey @jameskirsop. Are you able to provide a PR with a potential fix or one that provides an acceptance test that fails? So we can narrow down the issue.

@jameskirsop
Copy link
Author

@bastelfreak Yep! I actually hacked on together for my environments so I could use the rest of the module. You can review the diff here: jameskirsop@137212f

If you think it's PR worthy, I'm happy to create one, but I wasn't sure if it was up-to-scratch.

@bastelfreak
Copy link
Member

That looks okay, can you provide it as a PR? Please don't add :: leading for variables and use the facts hash facts instead of topscope variables.

@jameskirsop
Copy link
Author

jameskirsop commented Jul 23, 2019

It seems like #489 has fixed many of these issues, but I'm still having some.

In summary, when using the following:
site.pp

class { 'python':
    version => 'python36',
    virtualenv => present,
}

hiera for the group of hosts I'm wanting to deploy a virtualenv to

python::python_virtualenvs:
  "/etc/zabbix/userparam_venv_puppetmonitor":
    version: "36"
    virtualenv: "virtualenv-3"

I'm experiencing the issue described in this StackOverflow post.

If I run the suggested resolution:

etc/zabbix/userparam_venv_puppetmonitor/bin/python -m ensurepip --upgrade
Looking in links: /tmp/tmpozkrguk5
Requirement already up-to-date: setuptools in /etc/zabbix/userparam_venv_puppetmonitor/lib/python3.6/site-packages (41.0.1)
Requirement already up-to-date: pip in /etc/zabbix/userparam_venv_puppetmonitor/lib/python3.6/site-packages (19.2.1)

It would seem that when the virtualenv is set up, some incompatible version of pip is deployed.

Some additional info:

/etc/zabbix/userparam_venv_puppetmonitor/bin/pip --version
pip 19.2.1 from /etc/zabbix/userparam_venv_puppetmonitor/lib/python3.6/site-packages/pip (python 3.6)
pip3 --version
pip 8.1.2 from /usr/lib/python3.6/site-packages (python 3.6)

Perhaps we should upgrade pip3 on installation of python3, before it's used in a virtualenv?

@jameskirsop
Copy link
Author

jameskirsop commented Apr 14, 2020

Just trying to bump this one up, I've not come up with a suitable way forward yet, but still experiencing issues on CentOS7.

Things to factor in:

  • virtualenv-3 is not installed by this module, and it should be if used on CentOS with python3.6
  • virtualenv-3 should be the default vitualenv binary if the above is true, specified in the modules manifest

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

Successfully merging a pull request may close this issue.

2 participants