These are chat archives for coala/coala-bears

8th
May 2018
Viresh Gupta
@virresh
May 08 2018 08:37
@jayvdb
I am not sure if it is a problem with giturlparse, it works fine for bitbucket's git repositories
It's just that it breaks for bitbucket's hg urls for ssh style
(for git ssh, BitBucket uses : git@bitbucket.org:virresh/issueresolvinggit.git
for hg ssh, BitBucket uses : ssh://hg@bitbucket.org/virresh/mercurialtest )
We can definitely have a separate issue for that if needed
Viresh Gupta
@virresh
May 08 2018 08:46

Also wrt to the coala/coala-bears#2428 breakage sometime ago, I think a same rule W605 and another rule E252 is at work here

Although I could not reproduce it locally :worried:

John Vandenberg
@jayvdb
May 08 2018 09:58
Create an issue in giturlparse?
John Vandenberg
@jayvdb
May 08 2018 10:20
maybe need to rebase your PR?
Viresh Gupta
@virresh
May 08 2018 10:56

Create an issue in giturlparse?

Okay sure

maybe need to rebase your PR?

I've rebased it against master

And resolved all the conflicts in GitCommitBear that had occurred in the meanwhile
Viresh Gupta
@virresh
May 08 2018 11:08

Create an issue in giturlparse?

Made an upstream nephila/giturlparse#11
Though I am not very positive about getting it done at their end since the library was supposed to work only for git.

John Vandenberg
@jayvdb
May 08 2018 11:33
git-url-parse was also supposed to only work for git ;-)
Viresh Gupta
@virresh
May 08 2018 11:34
Yeah
But it works for hg as well :sweat_smile:
At least for now :sweat_smile:
John Vandenberg
@jayvdb
May 08 2018 11:34
need to add regression tests to ensure it cant stop working ;-)
Viresh Gupta
@virresh
May 08 2018 11:35
Ah
So that means a test in their repository ?
John Vandenberg
@jayvdb
May 08 2018 11:36
yup
Viresh Gupta
@virresh
May 08 2018 11:37
Cool
On it
Will try to send a PR
In the meanwhile, should we switch from giturlparse to git-url-parse ?
John Vandenberg
@jayvdb
May 08 2018 11:39
ya, no problem
do it as a separate commit in your PR
Viresh Gupta
@virresh
May 08 2018 11:40
Sure,
Thanks :D
Tobias Paepke
@paepke
May 08 2018 13:04
Searched through the docs and code but couldn't find an answer:
Is it possible to exclude a specific test or at least a result for a bear via the .coafile in a generic way?
Viresh Gupta
@virresh
May 08 2018 13:46

@jayvdb
PyCodeStyle bear is generating a warning W605 invalid escape sequence '\s' on CI
and this is generated on a regex string, so probably we need to disable this rule ?

Also it is generating a warning for E252 missing whitespace around parameter equals
Though I have fixed that one, but I don't know why all of these warnings are not coming up locally...

John Vandenberg
@jayvdb
May 08 2018 15:09
@virresh , what version of pycodestyle are you using locally ?
we're not disabling rules ;-)
Viresh Gupta
@virresh
May 08 2018 16:36
It's 2.3.1
John Vandenberg
@jayvdb
May 08 2018 16:40
well you need 2.4, as that is what we're using now
Viresh Gupta
@virresh
May 08 2018 16:40
Oh
The bear-requirements are yet to be updated ?
Thanks @jayvdb
:)
John Vandenberg
@jayvdb
May 08 2018 16:45
the bear requirements do not pin it to 2.3.x , so 2.4 is supported
Viresh Gupta
@virresh
May 08 2018 16:48

Oh
okay
And pycodestyle needs anything more other than just pip install pycodestyle==2.4 in order to get those new rules ?

My current terminal looks like:

(coala) viresh@viresh-PC:/mnt/Common/Earlier/GIT/coala/coala-bears$ pip freeze | grep pycodestyle
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
pycodestyle==2.4.0
(coala) viresh@viresh-PC:/mnt/Common/Earlier/GIT/coala/coala-bears$ coala
[WARNING][22:17:51] Section `all.todos` contain invalid language setting: 'Language `python3` is not a valid language name or not recognized by coala.'
Executing section all...
Executing section all.python...
Executing section all.flakes...
Executing section all.autopep8...
Executing section all.linelength...
Executing section all.CI...
Executing section all.commit...
Executing section rst...
Executing section all.PythonPackageInit...
[WARNING][22:17:59] No files matching '/mnt/Common/Earlier/GIT/coala/coala-bears/*.py' were found. If this rule is not required, you can remove it from section [all.PythonPackageInit] in your .coafile to deactivate this warning.
Executing section all.yml...
Executing section bash...
Executing section jinja2...
Executing section cli...
Seems the new rules are not present here yet...
But they show up on ci...
John Vandenberg
@jayvdb
May 08 2018 16:57
interesting problem ;-) beg other students to help you :P
jayvdb @jayvdb goes to sleep
Viresh Gupta
@virresh
May 08 2018 16:59
No issues
Thanks :D
I just found it
A coala --flush-cache did it
Thanks :D
John Vandenberg
@jayvdb
May 08 2018 17:06
that is a bug in coala .. ;-)
Viresh Gupta
@virresh
May 08 2018 17:08
Ah
But I don't know how to reproduce it
Will try reproducing sometime and file an issue report
Also our test cases got merged upstream in git-url-parse
;)

This one is https for hg on bitbucket
and This one is for ssh for hg on bitbucket

So I think this should work well for us now on :smile:

John Vandenberg
@jayvdb
May 08 2018 17:12
;)
@virresh , upgrading dependencies should flush the cache. It doesnt
Cache needs to record something about the dependencies to trigger flushing
Maybe executable file timestamp
Viresh Gupta
@virresh
May 08 2018 17:17
Got it
Will try writing instructions on reproducing this and file an issue :)
John Vandenberg
@jayvdb
May 08 2018 17:18
Or dep management needs to obtain version of installed dep and that should be stored in coala settings cache
difficulty high
Mischa Krüger
@Makman2
May 08 2018 22:15
Eww right you shouldn't be required to flush the cache on dependency upgrades... This is very annoying with the new caching system... @jayvdb
Flushing the cache though is a reasonable workaround :/
Okay actually it's not that annoying to implement when I think about it, but it's still kinda making things more complex again :3
Mischa Krüger
@Makman2
May 08 2018 22:21
@paepke it should be supported. Each result carries an "origin" (I know, it's a bad name for it...), That contains some extra information on the kind of errors (for example error code in form of Exxx or Wxxx). This depends on the bear though if they provide such identifying information (we are eager to improve it).
There should be settings to filter results based on origins, but I don't know the setting name myself. It could even be that we planned it for ages but haven't implemented it still.
Could you maybe file an issue to add it to the documentation? :) In case the feature doesn't exist for real, we would add another issue to actually implement it l ;)