Create python packages requirements.txt file from template #153
Conversation
enricostano
force-pushed
the
feature/python-packages-requirement-template
branch
from
ed8521f
to
6761357
Compare
enricostano
force-pushed
the
feature/python-packages-requirement-template
branch
from
6761357
to
ee6af03
Compare
|
On testing in a local host, I see that |
|
|
|
The same happens with: |
There was a problem hiding this comment.
Hey, thanks a lot for your work on this pull request!
I was thinking about rendering different requirements.txt for each environment as an interesting approach, and how it could conflict with our philosophy of uniform stages. Also, I was worrying about if not cleaning up old packages could potentially lead to unforeseen issues.
However, I've been thinking further, and it might be a bit simpler to lean on git a bit more for this.
We could achieve the same by having as many branches as needed. It's a little more streamlined and keeps extra complexity out of our Ansible role. Do you need a different requirements.txt? You've got a new branch!
Is there a use case I'm missing where this git strategy wouldn't work?
Don't get me wrong, your approach is totally valid, and I get why you suggested it. But maybe we can avoid adding more moving parts to our setup by using the tools we already have in place. What do you think?
P.S: I've added some code suggestions regardless.
P.S 2: Having the requirements.txt file rendered in the repository enables us to leverage the entire pip tooling ecosystem. We're currently using it on CI, Odoo Instances, etc...
| odoo11-addon-contract-variable-quantity==11.0.1.2.1 | ||
|
|
||
| In some case you want to deploy different versions of the same module to different hosts. | ||
| A typical case is when you have developed a custom module and need to deploy a packaged version of it to production but in local development environment you need to install it es editable. |
There was a problem hiding this comment.
| A typical case is when you have developed a custom module and need to deploy a packaged version of it to production but in local development environment you need to install it es editable. | |
| A typical case is when you have developed a custom module and need to deploy a packaged version of it to production but in local development environment you need to install it as editable. |
There was a problem hiding this comment.
We need the "as editable" part since in that use case you'll need to install the package with the -e option, it's just an example, a possible use case.
|
I think I'd feel more comfortable sticking with the requirements and adding the ability to uninstall -or delete from This way, we'd keep the advantages of the requirements file, and you could uninstall the pip package of the module you're working on in the dev environment. Even easier: Just setting it to another requirements file allows you to choose the requirements to install on a host (or any other dark Ansible condition you want) basis. You could have, e.g. However, haven't we already tackled this? 🤔 It rings a bell that the addon path precedence in |
|
Hi @oyale , thanks for your comments. I'll try to answer in line:
This is the strategy we first adopted in Som Comunitats and the result is quite a mess since you have to maintain 3 or more "main" branches at the same time.
I've also explored having multiple requirements files (you can also "chain" different files using pip
We will face this issue every time we change the
The CI argument is valid, although our "inventory" repos have a specific goal of defining variables used by As a last point I just wanted to add that the strategy proposed by this PR is what people from Coopdevs, Som IT, Som Comunitats, Som Energia and Som Connexio already agreed upon during the hackday on this specific topic. I'm sorry you couldn't join the session, but how do you feel about giving this approach a try and see if it really doesn't work as a solution? We can always change it and react to any issue it would generate in the future. What do you think? Many thanks! |
Co-authored-by: Pelayo García <[email protected]>
Co-authored-by: Pelayo García <[email protected]>
|
Hey, Enrico! Thank you for taking the time to respond in detail to my comments. I certainly appreciate the thoughts that have gone into the development of this strategy. Your explanation helped me better understand the big picture; however, I still have some questions. I would like you to expand on a few points, to help us all understand the context and reasoning behind the decisions made:
To wrap it up, I believe the loss of the As always, I appreciate your efforts to enhance our common software infrastructure and your willingness to engage in these discussions. Looking forward to your thoughts. Best, lai. P.S:
Absolutely. Maybe it would be nice to add the possibility to reset the |
I'm afraid I'm missing the point here. In fact, our proposal involves using already defined The inventories act as repositories for various data related to the hosts defined within them, including, as needed, YAML variable files, SSH public keys, CI files, .devenv files, linter/IDE config, and dependency files, don't they? Those that are intended to end in the remote host, such as SSH keys or
I understand where you're coming from, and generally, I would agree. However, I believe the case of dependency files might be an exception. Regarding the dependency centralization issue, as it stands, we already have the The proposed solution might create similar challenges to those we face with the |
|
Hi @oyale , thanks for your inputs. As we already discussed the majority of the items you ask about in the previous session, I would wait for the next one to further clarify these points. For the moment at Som Comunitats we'll use a fork of this project, waiting for this issue to get solved. Thanks again, Enrico |
|
Would you mind sharing the minutes from the session you're referring to? In any case, feel free to fork any of our code: it's Free Software. Forking instead answering the legitimate and reasoned concerns of peers is still valid. However, I would prefer to maintain a spirit and attitude aligned with the values of cooperativism and open source, working on common projects that serve the needs of as many people as possible. |
|
"I would wait for the next one to further clarify these points." You probably missed this part, I hope to see you in the meeting! |
|
I have read the whole message, thanks anyway, @enricostano.
Sure, just invite me and I'll do my best.
|
|
They have already done so, however, they do not recall assessing what alternatives to pip tooling would be used or what the specific problems are that prevent the use of different requirements.txt files. Let's please try to respect other people's time. |
Right now we blindly copy a text file to generate the
requirement.txtfile needed to install all the Python packages we need in our projects.In some case we need to change the content of
requirement.txtbased on many possibles ways (as many as Ansible variables allow).An example is when we want to install a package directly from our local development environment file system meanwhile in staging or production we still want those packages downloaded from Pypi.
With this PR we introduce 3 new variables:
odoo_role_odoo_community_packages: packages with Odoo modules that are mere dependencies of our project, we don't develop directly on themodoo_role_odoo_project_packages: Odoo modules that we develop for a specific project (classic Odoo custom module, etc)TODO
requirements.txtfile from templateUsage example
https://git.coopdevs.org/coopdevs/comunitats-energetiques/odoo-ce-inventory/-/merge_requests/61
⚠️ To test this PR with the Som Comunitats inventory you need to upgrade ⚠️
pippackage to a version > 20(this warning doesn't affect how this PR works, is just related to Som Comunitats needs, you can test this PR with other configurations)