Skip to content
This repository was archived by the owner on Jun 18, 2021. It is now read-only.

Virtualenv#183

Closed
atarkowska wants to merge 3 commits into
ome:masterfrom
atarkowska:virtualenv
Closed

Virtualenv#183
atarkowska wants to merge 3 commits into
ome:masterfrom
atarkowska:virtualenv

Conversation

@atarkowska
Copy link
Copy Markdown
Member

@atarkowska atarkowska commented Nov 18, 2016

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

Comment thread ansible/ci-deployment.yml Outdated
virtualenv_path: /home/{{ jenkinsuser }}/virtualenv
virtualenv_site_packages: "yes"
virtualenv_pip_rpm_dependencies:
virtualenv_pip_dependencies:
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what to install by default in any node?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a variable that can be overriden by group?

Comment thread ansible/ci-deployment.yml
virtualenv_path: /home/{{ jenkinsuser }}/virtualenv
virtualenv_site_packages: "yes"
virtualenv_pip_rpm_dependencies:
virtualenv_pip_dependencies:
Copy link
Copy Markdown
Member Author

@atarkowska atarkowska Nov 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which are doc dependences exactly?

Copy link
Copy Markdown
Member

@sbesson sbesson Nov 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sbesson for autogen I had to add #129. Does it mean is no longer the case? We don't need venv at all?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@manics are you ok with removal of omero_python_deps_profile and handling that as described below?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

@manics manics left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you avoid uninstalling/removing packages:

  • If other packages depend on this it may break them (e.g. in a previous PR removing python-pillow also removed cloud-init)
  • In this particular case the global pip will 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 }}"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Member

manics commented Dec 7, 2016

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?

@atarkowska
Copy link
Copy Markdown
Member Author

@manics could you give the example of what you are thinking of?

@manics
Copy link
Copy Markdown
Member

manics commented Dec 7, 2016

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.

@atarkowska
Copy link
Copy Markdown
Member Author

atarkowska commented Dec 7, 2016

I am not sure I understand why setting

role: virtualenv

vars:
    virtualenv_pip_dependencies:
    - ansible
    - shade

won't work in that case?

maybe I will add a quick test...

@manics
Copy link
Copy Markdown
Member

manics commented Dec 7, 2016

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants