Contributors mailing list archives
Re: 14.0 branchesby
Vauxoo, Moisés López Calderón
> Doing both if it's the contributor's responsibility to maintain oca_dependencies.txt and requirements.txt, then I'd say no because it will create additional burden on contributors.
Ok, how did you plan restore old behaviour like your first thread told us?
- "Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml"
Without these files the old behaviour is disabled totally.
> 2a. do people rely on the presence of oca_dependencies.txt and requirements.txt in their workflow ?
2b. do we want to guarantee their presence and correctness ?
For us today the answer for both are: yes
We are deploying using these files today.
In fact, we have a report of each sha and you can open a url with production sha vs staging one in order to see what changes were created.
In this report we have a warning if there is a repository with custom changes ("git status" feature).
if I like make a custom change for my oca-fork it is not an easy way to redirect all repositories to my organization like oca_dependencies.txt (we only change OCA by Vauxoo in the MQT script)
So, we will be forced to make a Python Package Repository to have our fork green.
I understand that we could loose these features using pip but I like the advantages using pip.
If we were warned a time ago, maybe we could think how to change it or prevent the effects and discuss it.
> That is a double open question, to be debated.
I agree with you.
This matter should be debated, with a good time before to decide change it
if both builds can't be enabled for 14.0
and 14.0 was already released 1 week ago.
Should we change the current way for 14.0 today even if it wasn't discussed before?