These are chat archives for translate/dev

8th
Sep 2017
Jose J. Martinez
@jjmcarrascosa
Sep 08 2017 11:49
@phlax Hi! I'm ready to continue a little with this. Will apply all the comments you proposed yesterday, I'll ping you when finished.
Jose J. Martinez
@jjmcarrascosa
Sep 08 2017 12:05
@phlax i have changed it to append and put the choices. But I don't know what else to do, they must be passed as an argument to the Project.objects.create command but as an array?
phlax
@phlax
Sep 08 2017 14:11
hi @jjmcarrascosa
you can actually pass them to the create method - see here https://github.com/translate/pootle/blob/master/pootle/apps/pootle_project/models.py#L65
Stuart Prescott
@llimeht
Sep 08 2017 14:28
Hi! Am I right in understanding that iso-codes is no longer needed and that pycountry is instead?
llimeht @llimeht can't see that pycountry is imported anywhere
phlax
@phlax
Sep 08 2017 14:33
hi @llimeht not sure what we did in the end - i think both datasets were partial
i would need to check
cant see it imported tho
hmm - it might be that we are using their iso files - can you raise a ticket and i can check more thoroughly
Stuart Prescott
@llimeht
Sep 08 2017 14:35
I can't see that ttkit opens any of the iso files eiher
Stuart Prescott
@llimeht
Sep 08 2017 14:40
@phlax : translate/translate#3692
from what I can see, pycountry gets its data from iso-codes in any case
phlax
@phlax
Sep 08 2017 14:44
so, just realised that this is for ttk not pootle
in ttk it does import pycountry
Stuart Prescott
@llimeht
Sep 08 2017 14:44
yes, sorry
oh?
phlax
@phlax
Sep 08 2017 14:44
in translate/lang/data.py
Stuart Prescott
@llimeht
Sep 08 2017 14:45
gah
phlax
@phlax
Sep 08 2017 14:46
iirc to it was for their translation files, which again iirc it was because they were more complete/maintained/up-to-date
not sure exactly
Stuart Prescott
@llimeht
Sep 08 2017 14:46
thanks, I have no idea how my earlier searching (and grepping) missed that
Stuart Prescott
@llimeht
Sep 08 2017 15:02
I have to say that I wished you listed the versions that were required in requirements/* rather than the versions that happen to be current at the time
phlax
@phlax
Sep 08 2017 15:03
not sure i follow
Stuart Prescott
@llimeht
Sep 08 2017 15:08
pytest==3.2.1 ← 3.2.1 is not actually required
phlax
@phlax
Sep 08 2017 15:10
is it being pulled in on a normal install ?
its in requirements/dev.txt
so i would have hoped it would only be pulled in if you did pip install -r requirements/dev.txt or similar
(maybe im missing the point)
Stuart Prescott
@llimeht
Sep 08 2017 15:11
If I'm building a package, I'm going to run the tests
Leandro Regueiro
@unho
Sep 08 2017 15:14
@llimeht We try to use the newest versions of the packages if possible, so if tests do pass with an older pytest that is just fine.
Stuart Prescott
@llimeht
Sep 08 2017 15:15
It would be better to only bump requirements when you use new features, otherwise you're offloading that work (and potentially some subtle breakage) to everyone else
phlax
@phlax
Sep 08 2017 15:16
we use requires.io to monitor deps
if it shows that we are "out-of-date" we tend to bump reqs
we hard-pin because not doing so can create a world of problems for future installs
Leandro Regueiro
@unho
Sep 08 2017 15:16
Before updating the requirements we check if there is any problem.
Stuart Prescott
@llimeht
Sep 08 2017 15:17
It flags things as outdated because you always use == rather than >=
and because it is outdated, you bump the == version when >=some_older_version would have been fine
phlax
@phlax
Sep 08 2017 15:18
hmm
Leandro Regueiro
@unho
Sep 08 2017 15:18
The thing is that >= created problems in the past, that is why we use ==
phlax
@phlax
Sep 08 2017 15:18
>= can also bring problems
yep
so we publish eggs with versions that we know work
Stuart Prescott
@llimeht
Sep 08 2017 15:18
and == creates problems too
and eggs are completely the wrong thing for me to consume
Leandro Regueiro
@unho
Sep 08 2017 15:18
But they are more manageable.
phlax
@phlax
Sep 08 2017 15:19
not so much for egg intalls
but i can see how that would be problematic in an os install
Stuart Prescott
@llimeht
Sep 08 2017 15:19
no, you're just offloading this work to me and I don't know what you've done
Leandro Regueiro
@unho
Sep 08 2017 15:19
If >= suddenly breaks tests we have to check which package created the problem and which version is ok.
Stuart Prescott
@llimeht
Sep 08 2017 15:19
so I have to review every single patch again
That review you can do as part of your CI and you know your code. I have to do it cold.
phlax
@phlax
Sep 08 2017 15:20
@llimeht if there is a way we can make it easier for you im happy to help
but
Stuart Prescott
@llimeht
Sep 08 2017 15:20
And every other package has to repeat that work
Leandro Regueiro
@unho
Sep 08 2017 15:20
Well, can you please contribute those patches to upstream?
phlax
@phlax
Sep 08 2017 15:20
most people install with eggs, so hard pinning makes sense for general release
Stuart Prescott
@llimeht
Sep 08 2017 15:20
no, hard pinning also means that people can't easily install things because of conflicting requirements
phlax
@phlax
Sep 08 2017 15:21
i think it does the opposite - but maybe i misunderstand
Stuart Prescott
@llimeht
Sep 08 2017 15:21
I end up spending my time wading through your patches to work out if pytest 3.2.0 is ok rather than 3.2.1 rather than doing more useful things
If, after that review, there is spare time, then you get patches from me...
phlax
@phlax
Sep 08 2017 15:22
the problems we were solving by moving to hard-pinning
Stuart Prescott
@llimeht
Sep 08 2017 15:22
what happens when ttkit specifies foo==1.2.3 and some other package specifies foo==1.2.2? You've just hosed your users
Leandro Regueiro
@unho
Sep 08 2017 15:22
Thanks. I hope that merging patches to upstream will reduce your workload in future packaging.
phlax
@phlax
Sep 08 2017 15:22
  • bugs were coming in which were caused by deps that were not tested
  • old installs were uninstallable
k - see the problem - but that is specific to os installs
Stuart Prescott
@llimeht
Sep 08 2017 15:23
no
Leandro Regueiro
@unho
Sep 08 2017 15:23
@llimeht We check for those issues before every release.
phlax
@phlax
Sep 08 2017 15:23
in a virtualenv egg install - its unlikely to be that you will get such conflicts
thats kinda the point of using virtualenv
Stuart Prescott
@llimeht
Sep 08 2017 15:23
assuming that you're lucky enough that you don't need to share virtualenvs with any other project
phlax
@phlax
Sep 08 2017 15:24
i think that is a fairly safe assumption
anyhow
Stuart Prescott
@llimeht
Sep 08 2017 15:24
the reality is that your tools are used as part of an ecosystem
I have this problem often enough...
phlax
@phlax
Sep 08 2017 15:24
i for one am really keen to make your life easier - so if there is a way we can keep some record or somesuch
i would be happy to
Stuart Prescott
@llimeht
Sep 08 2017 15:25
I just love the "oh, let's exit this virtualenv and enter this different one to run the next tool" dance
phlax
@phlax
Sep 08 2017 15:25
hmm
ive been using/coding/supporting python apps for best part of 20 years
and virtualenv was a revolution
in maintaining apps
Stuart Prescott
@llimeht
Sep 08 2017 15:25
Only if you run applications in total isolation
If one tool makes the input for the next tool, they are a pain the posterior
(or rather, they are with strict dependencies)
phlax
@phlax
Sep 08 2017 15:26
i can see how that is more likely for ttk
but for pootle or an app rather than lib - its really a lot easier for users having venvs and pinned deps
Stuart Prescott
@llimeht
Sep 08 2017 15:27
with looser deps, it's more likely that you can satisfy all of them within the one environment
The idea of exposing something to the network that is running inside a virtualenv scares me greatly