Virtualenv#183
Conversation
| virtualenv_path: /home/{{ jenkinsuser }}/virtualenv | ||
| virtualenv_site_packages: "yes" | ||
| virtualenv_pip_rpm_dependencies: | ||
| virtualenv_pip_dependencies: |
There was a problem hiding this comment.
what to install by default in any node?
There was a problem hiding this comment.
Should this be a variable that can be overriden by group?
| virtualenv_path: /home/{{ jenkinsuser }}/virtualenv | ||
| virtualenv_site_packages: "yes" | ||
| virtualenv_pip_rpm_dependencies: | ||
| virtualenv_pip_dependencies: |
There was a problem hiding this comment.
which are doc dependences exactly?
There was a problem hiding this comment.
I am not sure about the requirement for a virtualenv in ci-docs groups. As discussed in #158, the current nature of the documentation build stack (i.e. Ant + Sphinx) makes it not usable with a virtualenv in a Jenkins environment. Is there another use case?
There was a problem hiding this comment.
There was a problem hiding this comment.
Briefly discussed with @aleksandra-tarkowska, I think the issue is that different jobs have different strategies. Some of them use Jenkins Ant + globally installed Sphinx (BIOFORMATS build jobs) others use globally installed Ant + virtualenv (OMERO docs autogen jobs). Rationalizing might be a long term goal. To maintain compatibility, my feeling is that installing Sphinx in the system packages via sphinx-build and creating a virtualenv with --system-site-packages should maintain compatibility for both types of documentation jobs.
| - `omero_python_deps_profile`: Either `distribution` to use the distribution packages for Python modules where possible (default), or `pypi` to install recommended packages globally from PyPI using `pip`. | ||
| - `omero_python_deps_recommended`: If `False` install a minimal set of Python dependencies, default `True`. | ||
|
|
||
| If `omero_python_deps_recommended` False then use virtualenv role |
There was a problem hiding this comment.
@manics are you ok with removal of omero_python_deps_profile and handling that as described below?
There was a problem hiding this comment.
In principle that's fine. What's the plan for specifying the list of pip packages- will the full list always have to be specified in the playbook?
manics
left a comment
There was a problem hiding this comment.
@openmicroscopy/devops A general issue that's arisen here: I think we should try and avoid uninstalling anything at the system level, as it causes problems with other packages that may depend on it.
| when: "omero_python_deps_profile not in ['distribution', 'pypi']" | ||
|
|
||
| # TODO: Consider installing some of these with pip if the user requests it? | ||
| - name: omero python deps | pypi pillow uninstall |
There was a problem hiding this comment.
Can you avoid uninstalling/removing packages:
- If other packages depend on this it may break them (e.g. in a previous PR removing
python-pillowalso removedcloud-init) - In this particular case the global
pipwill also remove the files installed by yum, but the yum/rpm database still lists the package as installed, e.g.
[root@5a85874b4943 /]# yum install -q -y epel-release
[root@5a85874b4943 /]# yum install -q -y python-pip
[root@5a85874b4943 /]# pip freeze |grep Pillow
[root@5a85874b4943 /]# yum install -q -y python-pillow
[root@5a85874b4943 /]# pip freeze |grep Pillow
Pillow==2.0.0
[root@5a85874b4943 /]# python -c 'import PIL'
[root@5a85874b4943 /]# pip uninstall -y Pillow
Uninstalling Pillow-2.0.0:
Successfully uninstalled Pillow-2.0.0
[root@5a85874b4943 /]# pip freeze |grep Pillow
[root@5a85874b4943 /]# rpm -q python-pillow
python-pillow-2.0.0-19.gitd1c6db8.el7.x86_64
[root@5a85874b4943 /]# python -c 'import PIL'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named PIL
|
|
||
| - name: virtualenv | pypi {{ virtualenv_pip_dependencies }} | ||
| become: yes | ||
| become_user: "{{ virtualenv_user }}" |
There was a problem hiding this comment.
Can you make virtualenv_user default to root, since that's what you'd probably use in production.
| - `omero_python_deps_profile`: Either `distribution` to use the distribution packages for Python modules where possible (default), or `pypi` to install recommended packages globally from PyPI using `pip`. | ||
| - `omero_python_deps_recommended`: If `False` install a minimal set of Python dependencies, default `True`. | ||
|
|
||
| If `omero_python_deps_recommended` False then use virtualenv role |
There was a problem hiding this comment.
In principle that's fine. What's the plan for specifying the list of pip packages- will the full list always have to be specified in the playbook?
|
A more general question: Is this role intended to cover all uses of virtualenv, including use-cases which aren't related to OMERO/BF and related applications? |
|
@manics could you give the example of what you are thinking of? |
|
Suppose I want to setup a dedicated box for running infrastructure tasks (with jenkins, rundeck, manually, or some other method). This would require ansible, shade, python-openstackclients, and maybe some other python modules, but this has nothing to do with OMERO. If you want this role to be focussed on OMERO you can setup things by default, if it's meant to work for every use case that's more difficult. |
|
I am not sure I understand why setting won't work in that case? maybe I will add a quick test... |
|
It should work. My question was about what your intentions are. If you keep this completely generic you'll have to bear this in mind if you need to make future changes to the role, since it could be used anywhere. If you limit the scope you've got more freedom. |
This PR removes PyPI dependences to virtualenv
This PR is for the discussion on #sysadmin and maybe some clean-up first
cc: @sbesson @manics @jburel @joshmoore