PyCharm error on running debugger having installed with "snap"

Answered

I have upgraded from PyCharm 2017.3 under Ubuntu 17.04/10 to PyCharm 2018.2 under Ubuntu 18.04.  Previously I installed PyCharm via "manual" download & unzip.  This time I followed a post (https://www.jetbrains.com/help/pycharm/install-and-set-up-pycharm.html) which suggested installing it via

sudo snap install pycharm-community --classic

The installation works OK.  However, every time I start the debugger I now get two occurrences (in Console window) of error:

QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1000/snap.pycharm-community', please create it with 0700 permissions.

(The application uses Qt/PyQt, hence "QStandardPaths" is referenced during its start-up.)

XDG_RUNTIME_DIR is supposed to be an existing directory for temporary file storage.  Outside of PyCharm mine is already set by the system to /run/user/1000.  That directory exists and is usable.

I should not need to create the sub-directory either manually or by a script.  If I do create it, of course it gets deleted during logon/reboot (it's a temporary directory, something must clean it out completely).

It seems that PyCharm debugger alters this environment variable to append the snap.pycharm-community before launching the executable session.  That must come from the way I installed this time.  Either PyCharm should not alter that variable, or if it wants to use a "neat" sub-directory like this it should surely create it itself before launch.

Either: where/why it is altering the variable/not creating this directory

Or: should I uninstall the snap install way I did it and go back to re-installing PyCharm "manually" to avoid the issue

?

 

10 comments

The first link, https://forum.qt.io/topic/95916/linux-qstandardpaths-xdg_runtime_dir-points-to-non-existing-path, from 5 days ago is by me!  As you can see, I posted there to explain the behaviour and check why Qt cares about it.  When it came to sorting out why it has the extra "pycharm-community" appended to it which does yet exist, as you can see they referred me to the PyCharm forum :)

I have read through the second post, as best I can.  I do not think it applies to my situation.  There the problem seems to be with the user's top-level XDG temporary directory, in /run/user/<user-id> directory.  That is fine for me:

ls -ld /run/user /run/user/1000
drwxr-xr-x  3 root root  60 Oct 30 07:49 /run/user
drwx------ 12 jon  jon  280 Oct 30 12:42 /run/user/1000

The problem is the error message which complains about

/run/user/1000/snap-pycharm.community

That directory does not exist.  Creating it manually does not survive across login/reboot.

If I write a one-line (two, actually!) python program:

import os
print(os.environ['XDG_RUNTIME_DIR'])

and run it outside PyCharm, say in a terminal on my desktop, the value is

/run/user/1000

acceptable to all programs.  However, if I run it from within PyCharm --- both via Run or Debug --- I get

/run/user/1000/snap-pycharm.community

which does not exist.

Now, I do not doubt that this is a result of installing this time via

sudo snap install pycharm-community --classic

but the question is: where/how/what can I do about it/should I uninstall PyCharm and re-install not using snap?  It is PyCharm's documentation installation guide which I obeyed to try the snap install approach, not mine!  I would have thought this problem would arise for anyone following that, at least under my Ubuntu 18.04.  I don't know if you have the facilities to try it (I did an absolutely default Ubuntu install).

 

 

 

 

0

Please see https://youtrack.jetbrains.com/issue/CPP-12199#focus=streamItem-27-2912816-0-0. The problem is not on PyCharm side indeed. This is the 3rd party problem. You could communicate right in the comments of the issue.

0

@Sergey Karpov

Thank you, that's great.  I did Google for `XDG_RUNTIME_DIR` & `snap`, but somehow did not come across that thread.

There is a lot for me to read there, understand & consider, but you have given me the thread I need, thanks.

0

For anyone reading this.  As @Sergey Karpov said, this turns out not to be a PyCharm issue per se but rather a Linux snap one.  It is snap which changes the environment variable when PyCharm is installed & launched via snap.  A sample post about the problem behaviour is https://docs.snapcraft.io/186 :

> It was previously agreed to that snappy should set XDG_RUNTIME_DIR to /run/user/`id -u`/snap.$SNAP_NAME and create the directory[1][2]. Today, snappy sets XDG_RUNTIME_DIR but does not yet create the directory (the directory seems to be created by gtk3 apps at least).

So outside of gtk3 it will go wrong as per my post.  Which leaves all the references on the web stating that the best way to install PyCharm for Linux/Ubuntu etc. is via snap being unhelpful....

0

I have the same issue. Have you found a solution yet, or do you know about any news that the snap will be fixed soon? Are there any negative side effects of this? As far as I have observed one side-effect is, after reboot, PyCharm forgets my last open directory in the Project pane, which makes me re-open all the project directories in the hierarchy one-by-one, a bit annoying. Before using snap, they had been stayed open until I close myself. Perhaps the best way is to install PyCharm manually instead of the suggestion in PyCharm's website.

0

@arman  Regrettably I have given up on PyCharm fixing bugs I report, so I regard it as a fine product but not responsive to problems and you're stuck with however it works.  (More seriously than this issue, I find that now debugging now behaves unacceptably under Ubuntu 18/GNOME [when it hits a breakpoint], and so have had to stick at version 2018.1.6 as the last workable one.)  For your problem, I uninstalled the snap installation and have gone for manual download & install myself directly, which seems to work fine (and I have to do anyway to stick at the old version), so you may well want to try that.

0

Hi @Jnbarchan, thank you for your reply.  So far PyCharm team have fixed most of the bugs that I reported, though sometimes it takes time. Have you submitted this issue at YouTrack through the menu in the IDE? If not we can, and if you have already done it I can vote that issue and comment to take attention at YouTrack. Let me know.

What debugging issue do you have? I have the same version but have not noticed a problem. There were some debugging issues in the past but fixed with the recent versions.

0

@arman And thank you very much for taking an interest!

OK, my show-stopping debugging problem is posted in this forum, at https://intellij-support.jetbrains.com/hc/en-us/community/posts/360001352180-PyCharm-does-not-up-front-Debugger-window-on-breakpoint-hit.  I get really confused with all these, I have also referenced other posts in this forum and have brought this up on youtrack too.  I don't really want to know the difference between one and the other forum....

You will need to read through it carefully.  Different posts it references take you down different side-tracks, and possibly bits get fixed for one case but not for another.  Claims are made that a setting in a PyCharm dialog is the "reverse" way round in some versions, then others deny this, changing the setting did nothing for me.  Claims are made that my problem is fixed, but latest users say it is not, or at best it works "intermittently".

All I know is: as of the upgrade to PyCharm 2018.2 together with the move from Ubuntu 17 + Unity desktop to Ubuntu 18 + GNOME desktop, when you hit a breakpoint the PyCharm debugger no longer up-fronts itself.  You have absolutely no clue it has even hit a break.  By my definition of debugging at least it is "unusable" as a consequence.  Hence I downgraded to 2018.1 and have never accepted an upgrade since then.

What I need is: somebody check the out-of-the-box configuration of Ubuntu 18.04 + default GNOME with default PyCharm 2019.whatever.  Hit breakpoint on GUI program, does PyCharm up-front itself to show the breakpoint hit?  Reliably?  With any tweaks?  Until then I cannot contemplate re-upgrading.

If you would like to look into this I should be most grateful!

0

Hi @Jnbarchan, thank you for explaining the problem. With my use current case of PyCharm I am not affected with this debugging problem, luckily.

I commented for the snaps problem in youtrack here https://youtrack.jetbrains.com/issue/CPP-12199

A quick response is change of the state as Third Party Problem. Who knows maybe it is fixed someday in future in snaps if it is reported there... For now the best way is manual installation

0

Please sign in to leave a comment.