Nothing happens on :ViraServers

[maricn]

Hello! 👋

I have python3 package jira and I've tried putting my credentials to ~/.netrc and using jira from python console and it works well, I can connect and browse projects and everything.

However, using vira vim plugin nothing happens. I have created ~/.config/vira/vira_servers.json with content:

{
  "https://company.atlassian.net": {
    "username": "[email protected]",
    "password": "my freshly generated api key"
  }
}

When I issue :ViraServers command, a new buffer opens in a bottom split and it has a single empty line. When i press <cr> nothing happens - the buffer closes and that's it.

The same credentials (diff syntax) I use in ~/.netrc for jira python package which works fine.

I'm on arch

Linux work-x1c-arch 5.10.14-arch1-1 #1 SMP PREEMPT Sun, 07 Feb 2021 22:42:17 +0000 x86_64 GNU/Linux

and neovim:

NVIM v0.4.4                                                                                                                                                                                                                                                     
Build type: Release                                                                                                                                                                                                                                             
LuaJIT 2.0.5                                                                                                                                                                                                                                                    
Compilation: /usr/bin/cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconver
sion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/b
uild/neovim/src/neovim-0.4.4/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include                                                                                                                                       
Compiled by builduser                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                
Features: +acl +iconv +tui                                                                                                                                                                                                                                      
See ":help feature-compile"                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                
   system vimrc file: "$VIM/sysinit.vim"                                                                                                                                                                                                                        
  fall-back for $VIM: "/usr/share/nvim"                                                                                                                                                                                                                         
                                                                                                                                                                                                                                                                
Run :checkhealth for more info

I've tried using normal and dev version of the vira plugin - same behavior.

[n0v1c3]

Did you define the path in your vimrc?

It looks I may have left out the default.

let vira_config_servers = $HOME . '/.config/vira/vira_servers.json

I will have a closer look in a bit but I am working on a big one RIGHT now

[maricn]

I didn't have it, but I've tried with your suggestion. This is what I've tried:

let vira_config_servers = $HOME . '/.config/vira/vira_servers.json'
let vira_config_servers = '~/.config/vira/vira_servers.json'
let vira_config_file_servers = $HOME . '/.config/vira/vira_servers.json'
let vira_config_file_servers = '~/.config/vira/vira_servers.json'

It made no change in behavior.

And, no rush, man! :) Thanks for sharing this plugin with us! <3

[n0v1c3]

Are you using password or password_cmd I do assume your first test run is with password. Do you have a vira_projects.json file yet?

[n0v1c3]

Also check out branch VIRA-247 if you are on a larger server with many projects/versions that is the high priority fix right now.

Random though on my mind is to make sure you have a very simple __default__ inside vira_projects.json

[maricn]

Are you using password or password_cmd I do assume your first test run is with password. Do you have a vira_projects.json file yet?

• I was using password. Haven't tried with password_cmd.
• I didn't have vira_projects.json file. I tried adding one, but with no change. (with __default__ name too in case that's handled specially)

Also check out branch VIRA-247 if you are on a larger server with many projects/versions that is the high priority fix right now.

Random though on my mind is to make sure you have a very simple __default__ inside vira_projects.json

• Also tried checking out VIRA-247 branch (with __default__ project too) but that didn't solve it.

The server I'm connecting to is on *.atlassian.net and has a lot of projects and users and issues.

[n0v1c3]

@maricn this has been talked about between @mikeboiko and myself as well once async started. Users are next on my list after versions. I will need to expand the solution for what I am currently working on. I have done a quick push on VIRA-247 if you don't mind giving it a try for me.

You will need to stay out of the ViraSetUser and ViraFilterUsers menus for now.

We can also thank @chinwobble for having an initial issue leading this way.

[maricn]

I have done a quick push on VIRA-247 if you don't mind giving it a try for me.

Just did, no success. Still the same.

You will need to stay out of the ViraSetUser and ViraFilterUsers menus for now.

Got it...

[n0v1c3]

Did the stay away from the menu work as I did remove the initial user load from the code?

I guess did you log in?

[n0v1c3]

__default__ will just log into the server declared in it if you open any other menu before being connected.

[maricn]

I think we have some misunderstanding here. This is the state of vira plugin:

These are my vira config files:

» bat --decorations=always --style=header ~/.config/vira/vira_* | sed 's/"password": ".*"/"password": "REDACTED"/' | sed 's/"https:\/\/.*\.atlassian/"https:\/\/REDACTED.atlassian/' | sed 's/"username": ".*",/"username": "REDACTED",/'
File: /home/nikola/.config/vira/vira_projects.json
{
  "__default__": {
    "server": "https://REDACTED.atlassian.net"
  }
}

File: /home/nikola/.config/vira/vira_servers.json
{
  "https://REDACTED.atlassian.net": {
    "username": "REDACTED",
    "password": "REDACTED"
  }
}

This is how my nvim looks like right after I type :ViraServers<CR>:

And it stays like that. Whatever I press next, the bottom horizontal split closes and nothing happens, ie. I get this:

[mikeboiko]

@maricn, can you try deleting your 2 json files please?
vira will interactively prompt you for your server/credentials.
If this is successful, try running :ViraIssues

[maricn]

@maricn, can you try deleting your 2 json files please?
vira will interactively prompt you for your server/credentials.
If this is successful, try running :ViraIssues

OK, I think my problem probably lies elsewhere. I removed the config files, but I got no prompt.

[mikeboiko]

Yea it seems like either the per-requisites or the vira plugin isn't loaded properly.
Are you running multiple versions of python on your machine through pyenv?
Can you open neovim and run :py3 import jira successfully?

[n0v1c3]

I didn't have a chance to try but make sure it is not referenced in your .vimrc as well for this test.

[maricn]

OK, whoa, I got it 🤦 ! My :checkhealth provider returned:

## Python 3 provider (optional)
  - INFO: Using: g:python3_host_prog = "/usr/bin/python3"
  - INFO: Executable: /usr/bin/python3
  - INFO: Python version: 3.9.1
  - INFO: pynvim version: 0.4.2
  - WARNING: Could not contact PyPI to get latest version.
  - ERROR: HTTP request failed: error: curl error with https://pypi.python.org/pypi/pynvim/json: 23

It is clashing with my .curlrc:

# -- curl default configuration --

# -- deliberately unused --
# follow the redirects
# -L
# output to file
# -o /dev/null
# verbose output (more Vs, more verbose)
# -vvv

# silence the progress bar
-s

# ignore TLS verification
insecure

# write out some useful info to stderr
write-out = "\n%{stderr}           �[33mremote_ip:  �[31m%{remote_ip}\n              �[33mscheme:  �[31m%{scheme}\n       �[33mresponse_code:  �[31m%{response_code}\n                �[33msize:  �[31m%{size_download}\n        �[33mredirect_url:  �[31m%{redirect_url}\n       �[33murl_effective:  �[31m%{url_effective}\n\n     �[33mtime_namelookup:  �[31m%{time_namelookup}\n        �[33mtime_connect:  �[31m%{time_connect}\n     �[33mtime_appconnect:  �[31m%{time_appconnect}\n    �[33mtime_pretransfer:  �[31m%{time_pretransfer}\n       �[33mtime_redirect:  �[31m%{time_redirect}\n  �[33mtime_starttransfer:  �[31m%{time_starttransfer}\n                     �[33m----------\n          �[33mtime_total:  �[31m%{time_total}\n�[30m"

# send headers to stderr
-D /dev/stderr

It seems that pynvim is struggling with it because it interprets the headers from the curl response, and I redirect them to /dev/stderr by default.

Sorry, sorry, sorry, everyone, definitely not in your scope! Thank you for helping me find out the issue! 🙏

[maricn]

Although, now when I go with :ViraServers and input my server, username and password, I get:

Exception ignored in: <function Magic.__del__ at 0x7feb0d5a6af0>
Traceback (most recent call last):
  File "/home/nikola/.local/lib/python3.9/site-packages/magic.py", line 129, in __del__
    if self.cookie and magic_close:
AttributeError: 'Magic' object has no attribute 'cookie'

[mikeboiko]

Glad you got that issue figured out.
That's a strange one. I'm also using python 3.9.1 and I don't get this error.

[mikeboiko]

Try the fix suggested in https://stackoverflow.com/questions/64213739/attributeerror-magic-object-has-no-attribute-cookie-while-using-python-jira

[n0v1c3]

@mikeboiko if that works we will probably just add it officially to help future users as well.

[mikeboiko]

@n0v1c3 gotta hate it when those magic cookies don't play nicely ;)

[n0v1c3]

Lol! They were much more fun in highschool for some reason.

[maricn]

@mikeboiko if that works we will probably just add it officially to help future users as well.

Yes, spread the word about them! 🍄🍪

Btw, maybe you should also document that larger servers will have issues connecting unless you set up a filter for the repo to narrow down the project. For me it's not just slow, but also errors out and doesn't work without a filter.project entry in vira_projects.json. (I'm still on VIRA-247 branch). Also, even when it does, is painfully slow, so let me know if I can contribute to testing that topic in some other issue.

[n0v1c3]

When was your last update on VIRA-247? It should be nice to you now. I am interested in feedback for sure and, the filters are broken on it right now. If you have a "Vira" filter it will still show all your versions from all projects. I am working on that and then pushing it to dev once approved.

Filters will not be required for connection speed in the very near future. This was because of some work around we created to get more information than we should have by running way too many queries. I have basically fixed projects/versions on that branch and can get onto users shortly with what I have learned and created.

[n0v1c3]

We also motivate any information from you pushed straight into the README. The Trouble Shooting Tips section will need to start to grow and clean up to help new users set up.

I would like to welcome you to the team and there is no better way than the "README didn't help me".

One more thing, for the painfully slow are you referring to how fast the list grows or how fast vim runs?

[n0v1c3]

I also brought back that users line in the connect function inside python if that fixed it earlier then you can comment it out for your temp patch.

[maricn]

When was your last update on VIRA-247? It should be nice to you now. I am interested in feedback for sure and, the filters are broken on it right now. If you have a "Vira" filter it will still show all your versions from all projects. I am working on that and then pushing it to dev once approved.

Yes, I'm up to date, at e433204 and that's where I noticed the slowness too.

One more thing, for the painfully slow are you referring to how fast the list grows or how fast vim runs?

I'm referring to how fast vim runs. It seems very clogged, UI is not very responsive for minute(s). I can use it, but very pedestrian style, 500+ms lag or so. Btw, I noticed #45 and I'm aware of the async in VIRA-247, and I think my stuff still takes minutes to load asynchronously in the background and it's still not very much getting out of the way of using vim.

I also brought back that users line in the connect function inside python if that fixed it earlier then you can comment it out for your temp patch.

I'm not sure what kind of setups are you testing this on, but I've been in a couple of companies that had 10+ times more stuff on JIRA than my current one, so I'd expect that to be an important topic for this plugin. Two things I can see off the bat can improve performance:

• caching data locally
• changing the implementation for getting users

Neither is unfortunately very easy to implement.

I also brought back that users line in the connect function inside python if that fixed it earlier then you can comment it out for your temp patch.

Commenting out that line does make it faster to fetch the projects, but the laggy performance persists looong even after the response arrives (and is printed out).

We also motivate any information from you pushed straight into the README. The Trouble Shooting Tips section will need to start to grow and clean up to help new users set up.

Will do!

[n0v1c3]

• Caching is high on the list
• Getting users even higher
  • I know where the issue is for users

There is a line in autoload/vira.vim let s:vira_async_timer = 1 try changing that I to a 25/50/250 these are in ms. I think I pushed the wrong number in while playing.

[n0v1c3]

If a lower number in particular works without being noticable in vim we have won. That async will run one background query per Xms. I will need to add a juggle in for users and versions. The base of which is one at a time version then user then version then user... For each list "quickly" once then you will see an adjustment of that timer in the async function once list is complete.

Fight now the list is only project/versions

[maricn]

There is a line in autoload/vira.vim let s:vira_async_timer = 1 try changing that I to a 25/50/250 these are in ms. I think I pushed the wrong number in while playing.

It doesn't matter how big I make that number (10/50/100/500/5000) - at the moment when it triggers the request it slows down vim UI considerably. [So increasing the number helps a bit - it buys users some time to experience responsive UI, but it doesn't remove the interference.] It leads me to conclusion it is not truly multi-threaded solution, but merely get-out-of-my-sight kind of approach to async.

I see https://github.com/skywind3000/asynctasks.vim that might jump to rescue, but tbh, it seems like too much effort. Local caching would definitely help a lot and probably completely overshadow the need for solving that issue.

EDIT: I've just noticed your comments on #45 regarding async in python - that would seem like a good approach to solving the problem with unresponsiveness.

If a lower number in particular works without being noticable in vim we have won. That async will run one background query per Xms. I will need to add a juggle in for users and versions. The base of which is one at a time version then user then version then user... For each list "quickly" once then you will see an adjustment of that timer in the async function once list is complete.

Fight now the list is only project/versions

From my experience people find the weirdest ways to use JIRA that I could never think of. :) I'm for instance not using versions in my current three projects. And the products I work on are not 1:1 with the JIRA projects, and neither of those is 1:1 with git repos. And I've seen a lot of weirder stuff with custom workflows and what-not.. Just saying that QA of JIRA related projects like this plugin can explode the number of features. Beware of specializing too narrowly for your known use case. 🖖

[n0v1c3]

I have a very big dream but I don't want to have even my hopes that high (this async backend and frontendish was not a slow down).

My real goal is going to be what do you want vira to infect next. I think that started when my s key started to select, change issues mentioned in reports and open the browser. I knew there would be no end after that.

[n0v1c3]

I like the idea of a live chat option added since the async now. Although, I will stay on jira topics for the first official release.

VIRA-69 is ironically an epic issue. Then we are in a clean up what we can in the code and frontend.

Some major will never ends but the nicer they look the better are thing that will eventually become very not fun to handle all code style formats when wrapped. And of course we want a nice cleanup of our readme and actual work done on the vim Vira help to make that look cleaner and faster to understand.

I have released that idea now feel free to keep them coming.

[n0v1c3]

@maricn you will see on my other active issue that hopefully the loading of the projects/versions is not an issue and up for testing. I also mentioned that my next step will be the users to update in the same way. This is currently on branch VIRA-247 and once good enough for the bigger players will get merged into dev and most likely quickly into the master after some clean-up rounds.

Let me know if I have broken anything or simply made it better. Users should not be as hard now that I have made this "almost" work in vim.

[n0v1c3]

@maricn I have closed that other isses with @chinwobble / #45 at least for now as we move to hopefully start creating and endless list of new issues. I will always appeaser new issues being found in my tools being built to help solve the issues for other people around the world.

I am still very interesting in hearing your feedback and will leave this issue open as I am beginning my proper clean-up process. This was the other big one that turned out to be very much the same issue as we got closer and closer.

I am going through clean up and thinking. Push to dev, test (issues for those tools somewhere) I see that I have at lest more that a few people active using the dev branch and I know how far it stays ahead of the master branch so I am not too worried for a what will be a VERY large upgrade.

[maricn]

@n0v1c3 Now it works much better with the latest updates. The cursor just barely stutters when holding j/k, and the loading times seem to have improved in general.

Thank you for getting so involved with my comments. :)

[n0v1c3]

@maricn I am glad to hear that it is working better for you now and a thanks for these issues leading to a much better feature than expected.

As we talked about, consider yourself becoming part of the team one piece at a time and pointing out everything I have done wrong. There is no way we can make software great for all of us otherwise.