Archives
Contributors
Re: 14.0 branches
El mar., 13 de oct. de 2020 a la(s) 01:57, David Beal (david.beal@akretion.com) escribió:
+1 for generated requirements.txt and oca_dependencies.txt too if possible
IMHO I think that can not be optional but mandatory for the sake of stability and take 2 versions to stabilize.
I wonder how will be the management of a wired repository.
I mean:
oca_dependency.txt.
folder git/repo branch
And force the dependency be taken/updated from it.
Regards.
I love the effort that has been made to autodiscover the dependencies from __manifest__Please don't discourage it with arguments about your own deployments.You may use pip in OCA workflow as proposed, and use git for your development/production as I do everydayYou have to decouple things for your own interestmy 2 ctsLe mar. 13 oct. 2020 à 08:47, Stefan Rijnhart <stefan@opener.am> a écrit :+1 for generated requirements.txt and oca_dependencies.txt
Stefan
On 12-10-2020 14:52, Alexandre Fayolle wrote:
I'm happy with generated requirements.txt and oca_dependencies files. This will remove some errors caused by manual management of these files anyway.
Regarding oca_dependencies: I use them to easily find when an addon is defined, where to direct a contribution, etc. I also happened to "discover" some OCA repositories that way.
Regarding requirements.txt: the latest version of Odoo's runbot uses these to install the requirements. It will help using OCA repositories on Odoo.sh, and I think it is a valuable service we provide to our users.
Regarding pip installation of addons, I'm not sure this is available on odoo.sh, and I think this is a use case we should not underestimate.
Le lun. 12 oct. 2020 à 09:07, Mignon, Laurent <laurent.mignon@acsone.eu> a écrit :
HI Folks,
I think it's very important to keep the debate open and to present your arguments in a constructive way.I must admit that I am a little saddened to read accusations of half-truths when the process is meant to be open and constructive. It seems to me that the goal here is not to impose a new methodology but to confront our practices with those of the python community. The fact that the aim of this approach is to simplify the maintenance of our OCA repositories as well as to reduce the learning curve for new developers, I find this more than remarkable and valuable.
Since many integrators' tools/processes are now based on the oca_dependencies.txt and requirement.txt files, in view of the discussion it seems necessary that somehow these should be available again. It seems to me that automating the generation of these files would be more than beneficial because it would avoid inconsistencies in the future for all the processes based on them.
Over the years I have used different tools and methodologies to try to improve the management of our dev -> prod processes of our python projects. I personally contributed to buildout, imagined and wrote git-agggregator, .... The goal has always been to improve the traceability and reproducibility of our developments and deployments. Today, and thanks to the evolutions around pip, I'm happy to see that python tools allow me to improve and simplify these processes without having to use specific tools. (While bringing more freedom and features).
Is it possible to envisage an evolution of our integration mechanisms towards pip support while retaining the necessary elements for the other approaches developed by the various parties?
I find it motivating to confront this approach with all the use cases of each other in order to determine the limits of this approach. This will at least allow us to improve our knowledge and perhaps correct certain ideas.
Regards
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 04:06 - 14 Oct 2020
Reference
-
14.0 branches
Dear fellow contributors,The 14.0 branches are being created as I post this message.They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.Special thanks to Jairo Llopis for his work on this topic.I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.2. Travis installs dependencies with pip, including addons of other repos1. The project description in README.md must be updated manually by PSCs.Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.The main expected benefits are:- less redundancy (the manifests are enough to discover dependencies)- reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installedIf a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]3. If you need local changes to the dotfiles let's discuss themThere are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.As usual, don't hesitate to let me know of any issue.That's all for now, folks. Happy migration!-sbi--
by Stéphane Bidoul - 09:21 - 8 Oct 2020-
Re: 14.0 branches
Ah, funny. I just stumbled upon a forgotten PR of mine to generate requirements.txt.Looks like another version of me had anticipated the discussion, and then forgotten about it :)I'll see if that works and add support for generating oca_dependencies.txt as soon as possible.I take the opportunity to say thank you to all those who expressed support for the work done on OCA infrastructure.And I myself say a huge thank you to all those who contribute to improve it and keep it humming.-sbiOn Wed, Oct 14, 2020 at 1:47 PM Maik Derstappen <md-lists@derico.de> wrote:Am 13.10.20 um 10:57 schrieb Daniel Reis:
The version pinnings it self, could be defined in a constraints.txt, so that it is separated from the packag names:I believe the external_dependencies manifest key supports pinned versions. On 13/10/2020 08:36, Pedro M. Baeza (Tecnativa) wrote: > Stéphane, how to pin specific Python libraries versions in this > workflow in the generated requirements.txt? We have several places > with this requirement.
https://pip.pypa.io/en/stable/user_guide/#constraints-files
one could install this as follow:
pip install -r requirements.txt -c constraints.txt
-- cheers Maik Derstappen derico - web development & consulting >> Python - Plone - Odoo - Pyramid - Django_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 10:56 - 15 Oct 2020 -
Re: 14.0 branches
+ 1 for generating oca_dependencies.txt and requirements.txtIn any case, thanks a lot for your work StéphaneOn Tue, 13 Oct 2020 at 09:32, Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:On Mon, Oct 12, 2020 at 5:32 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote: > I'll see if I can find an easy way to generate oca_dependencies.txt > and requirements.txt. I have been giving some thought to this and I believe it is possible to create a reasonably fast pre-commit hook that generates oca_dependencies.txt and requirements.txt. Roughly, requirements.txt would be generated from the external_dependencies manifest keys in the repo. oca_dependencies.txt would be generated by looking at the website key in manifests of first level dependencies which we find in the url key of wheels (it is supposed to have the form https://github.com/OCA/{repo} and we can enforce if we don't do it yet). There are some devils in the details (like what to do with test-requirements.txt, and what to do when there are conflicting requirements) but that seems manageable at first glance. The result should be identical to manually crafted files and help ensure consistency. Would that work for people who care about those two files ? For the rest, yeah, I guess this thread shows how deeply people care about their project workflows, and that is only normal. I can only repeat that *this should not have any impact on them*. When I have more time I'll answer to some comments that worry about a pip project workflow being broken or something (spoiler: it is not :) Cheers, -sbi
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lorenzo Battistini
https://github.com/eLBati
by Lorenzo Battistini. - 11:06 - 14 Oct 2020 -
Re: 14.0 branches
PS: can you share the command to tray it from github?Hi Nhomar,the way I prefer:pip install -e git+https://github.com/odoo/odoo.git@c107edf7077399c2ffa60b85a291ec3830d8432d#egg=odoo
--Lorenzo Battistini
https://github.com/eLBati
by Lorenzo Battistini. - 11:00 - 14 Oct 2020 -
Re: 14.0 branches
Hi Pedro,in case you can't avoid it, you can pin the version in setup.py file, like the following:On Tue, 13 Oct 2020 at 09:36, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:Stéphane, how to pin specific Python libraries versions in this workflow in the generated requirements.txt? We have several places with this requirement.Regards.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lorenzo Battistini
https://github.com/eLBati
by Lorenzo Battistini. - 10:46 - 14 Oct 2020
-