[question] specifying Exact Requirements on requirements.txt file

[tasdikrahman]

I was curious about the part where in our requirements.txt and test-requirements.txt we were not specifying the exact versions of the pip modules that we are using.

Reason being ~we might now if a~ if there is a particular/newer version released for those specific pip modules, ~it could create~ there is the possibility of it creating a failure during runtime.

[lukas-bednar]

Hi,

requirements.txt are requirements to use these roles. test-requirements.txt are requirements to run tests for these roles.

If you want I can create freeze-requirements.txt which contains specific versions to run these roles. Just tell me and I will generate it ... that file will be just result of pip freeze command.

On other hand you / we usually use others roles from other repositories. like ntp/chrony for time sync, limts, ssh ... all these roles we put into one playbook and run them for our deployment.

I am curious how are you going to combine frozen requirements of every role you use into one environment.

[StLuke]

Due to usage of multiple roles as @lukas-bednar mentioned I believe this is not the result we wanna get, however some freeze-requirements.txt would be great to versionlock working package versions just for documentation purpose and for debugging in case of compatibility problem

[tasdikrahman]

Hey @lukas-bednar

I am curious how are you going to combine frozen requirements of every role you use into one environment.

From the way I see it, the only dependency that's required on the box from where you are running your ansible-playbook. You would only have ansible as the only requirement. Is that correct?

If you want I can create freeze-requirements.txt which contains specific versions to run these roles. Just tell me and I will generate it ... that file will be just result of pip freeze command.

I agree that all use a different pip workflow. I use this one in particular as suggested by kenneth. So my question arose from this article.

[tasdikrahman]

Hey @StLuke,

If I refer just the requirements.txt file in the root dir. Referring to @lukas-bednar 's comment on combining roles in a single playbook. I am guessing the version of ansible would still be the same. i.e if let's say ntp was having ansible version 1.9.0. The other roles combined and being run would also have the same ansible version running them.

Citing the Zen of python

Explicit is better than implicit.

Please let me know if I am missing out something in this discussion

[lukas-bednar]

From the way I see it, the only dependency that's required on the box from where you are running your > ansible-playbook. You would only have ansible as the only requirement. Is that correct?

What I would do is pip freeze -r requirements.txt that generates following output.

ansible==2.3.0.0
## The following requirements were added by pip freeze:
appdirs==1.4.3
asn1crypto==0.22.0
cffi==1.10.0
cryptography==1.8.1
enum34==1.1.6
idna==2.5
ipaddress==1.0.18
Jinja2==2.9.6
MarkupSafe==1.0
packaging==16.8
paramiko==2.1.2
pyasn1==0.2.3
pycparser==2.17
pycrypto==2.6.1
pyparsing==2.2.0
PyYAML==3.12
six==1.10.0

and that is what I can give you as requirements-freeze.txt this file would be updated per each release viz https://github.com/rhevm-qe-automation/ovirt-ansible/releases

From that article you shared here, my requirements.txt is his requirements-to-freeze.txt. And I can provide you requirements-freeze.txt which is his requirements.txt :-)

[tasdikrahman]

Hey @lukas-bednar ,

I was having a look at the https://github.com/ansible/ansible/blob/devel/requirements.txt file and they too have a very loosely defined requirements.txt

# Note: this requirements.txt file is used to specify what dependencies are
# needed to make the package run rather than for deployment of a tested set of
# packages.  Thus, this should be the loosest set possible (only required
# packages, not optional ones, and with the widest range of versions that could
# be suitable)
jinja2
PyYAML
paramiko
pycrypto >= 2.6
setuptools

So if it's working for them, it should also work for us. As I mentioned, everyone would be having a different pip workflow. If the current one works for us, no need trying to break the existing solution.

Although the only places I saw the requirements.txt would be tox.ini file for linting purposes. What do you think?

[lukas-bednar]

I think that if you want to be on safe side, I would recommend you to install everything you need inside of virtualenv, test it whether it works for your purposes, and then run pip freeze > my-requirements.txt.

So now you have file which describes your dependencies and it was tested that it works for you. Then everytime you need to use it, you just run pip install -r my-requirements.txt and it will look always same ... same packages same versions.

[tasdikrahman]

I think that if you want to be on safe side, I would recommend you to install everything you need inside of virtualenv, test it whether it works for your purposes, and then run pip freeze > my-requirements.txt

I think you misinterpreted that I was facing issues with running the ansible-playbook. That's not the case. 😄 But anyhow. A simple pip install ansible has been doing the trick for me everywhere.

I am closing this issue. I think for this particular project it's better to leave the requirements file as loosely defined. Or if you have other things in mind. Please reopen the issue. Would be happy to discuss.

Cheers!

EDIT: Added some details