We Keep Coding

Pycharm CE not hitting breakpoints in my Django project

I have my project properly configured to run manage.py in the right place, with the right settings.
I also have debug breakpoints set in a method that I know with certainty is being executed (I've put a print statement there and it executed as expected). The breakpoints are not disabled or conditional:
When I hit the "Run in debug mode" button, using the above run configuration (I'm sure it's the same one because it's the only one I've configured for this project), this is the console output I get:
pydev debugger: process 38083 is connecting
Connected to pydev debugger (build 192.5728.105)
Watching for file changes with StatReloader
Performing system checks...
System check identified no issues (0 silenced).
December 23, 2020 - 19:22:22
Django version 3.1.4, using settings 'FEArena.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
When I tried putting a breakpoint in manage.py, it worked as expected, triggering just when I hit the 'debug' button. However, after the app has started, when I use a REST client to trigger the above method, the one with breakpoints in it, the breakpoints do not trigger and the debugger doesn't start. I get a 200 OK response in my REST client, but PyCharm does not stop and execute the debugger at any point.
I looked at other answers that advised setting "Gevent compatible debugging" (which I don't have, because I'm using Community Edition), and I've tried deleting the .idea/ folder for the project, which also didn't fix the issue. I'm not sure what else could be causing this. I just want to debug my program.
My PyCharm version information is
PyCharm 2019.2 (Community Edition)
Build #PC-192.5728.105, built on July 23, 2019
Runtime version: 11.0.3+12-b304.10 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.15.7
GC: ParNew, ConcurrentMarkSweep
Memory: 4029M
Cores: 8
Registry:
Non-Bundled Plugins: com.karateca.jstoolbox, mobi.hsz.idea.latex, net.seesharpsoft.intellij.plugins.csv, nl.rubensten.texifyidea, org.intellij.plugins.markdown
What could be causing the breakpoints to not be triggered, and how do I fix this? I need breakpoints to debug other parts of my program.

Are you running your server in a console by any chance? If thats the case try stopping the server runing in console and restart the one in PyCharm

I was having a similar issue previously in PyCharm when I was invoking executor.submit. I had to insert a line requesting the results of the code in order to re-invoke the expected debugging behaviour. If your code is threaded, you may wish to start there.
future = executor.submit(control, channel) # spawn a function control(channel)
print(f'Future result is: {future.result()}') # new line I had to add to enable debugging
Edit: Adding the link to the thread that helped me with similar behaviour in PyCharm. concurrent.futures.ThreadPoolExecutor doesn't print errors

My current working configuration is on this :
It does not have any script path or parameters.
When I click on the "Debug" green button, the command automatically launched is :
/Users/.../virtualenv/bin/python /Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/pydevd.py --multiproc --qt-support=auto --client 127.0.0.1 --port 55583 --file /Users/.../manage.py runserver 8000
What about yours ?

Hi I am writing this answer as I cannot comment because of my reputation no. By any chance, did you installed cython debugger toolkit that pycharm keeps on suggesting? If so, i have faced the same issue. The solution is to delete cython speedups somehow. You can follow this link to do that.
Basically you have to go to the directory called _pydevd_bundle and delete pydev*.so files. Now that requires root privilege. If you have that and you are able to delete them, then most likely it will work(provided you had installed cython debugger extension).

Django manage.py runserver command freezing on OSX

I have a few different systems that I use for development of a Django project. The main being Linux, then Windows, and then Mac...all systems implement development using Pycharm
Up until about a week ago I was able to develop my Django project on Mac just fine, I could run the server and check updates as usual, however, for some reason I cannot seem to figure out, the terminal just freezes for about 5 minutes when I run:
python3 manage.py runserver 8000
The server still starts after that 5 minutes but the startup time is quite literally awful, and I do not know what to look at to figure out where the issue is.
I have not changed my code between work and home, just pulled directly from Git and I have the same issues. On my Windows System at home the Django app also runs within a few seconds of starting the server, as does the Linux system at work, so it seems to be only happening on OSX.
Again, I am using Pycharm, but even if I manually enter the project directory and run the server, the startup time is slow
Has anybody run into issues like this, or where can I look to try and find the cause of the error?

mod_wsgi: Reload Code via Inotify - not every N seconds

Up to now I followed this advice to reload the code:
https://code.google.com/archive/p/modwsgi/wikis/ReloadingSourceCode.wiki
This has the drawback, that the code changes get detected only every N second. I could use N=0.1, but this results in useless disk IO.
AFAIK the inotify callback of the linux kernel is available via python.
Is there a faster way to detect code changes and restart the wsgi handler?
We use daemon mode on linux.
Why code reload for mod_wsgi at all
There is interest in why I want this at all. Here is my setup:
Most people use "manage.py runserver" for development and some other wsgi deployment for for production.
In my context we have automated the creation of new systems and prod and development systems are mostly identical.
One operating system (linux) can host N systems (virtual environments).
Developers can use runserver or mod_wsgi. Using runserver has the benefit that it's easy for debugging, mod_wsgi has the benefit that you don't need to start the server first.
mod_wsgi has the benefit, that you know the URL: https://dev-server/system-name/myurl/
With runserver you don't know the port. Use case: You want to link from an internal wiki to a dev-system ....
A dirty hack to get code reload for mod_wsgi, which we used in the past: maximum-requests=1 but this is slow.

Preliminaries.
Developers can use runserver or mod_wsgi. Using runserver has the
benefit that you it easy for debugging, mod_wsgi has the benefit that
you don't need to start the server first.
But you do, the server needs to be setup first and that takes a lot of effort. And the server needs to be started here as well though you can configure it to start automatically at boot.
If you are running on port 80 or 443 which is usually the case, the server can be started only by the root. If it needs to be restarted you will have to ask the super user's help again. So ./manage.py runserver scores heavily here.
mod_wsgi has the benefit, that you know the URL:
https://dev-server/system-name/myurl/
Which is no different from the dev server. By default it starts on port 8000 so you can access it as http://dev-server:8000/system-name/myurl/. If you wanted to use SSL with the development server you can use a package such as django-sslserver or you can put nginx in front of django development server.
With runserver you don't know the port. Use case: You want to link from >an internal wiki to a dev-system ....
With runserver, the port is well defined as mentioned above. And you can make it listen on a different port for exapmle with:
./manage.py runserver 0.0.0.0:9090
Note that if you put development server behind apache (as a reverse proxy) or NGINX, restarting problems etc that I have mentioned above do not apply here.
So in short, for development work, what ever you do with mod_wsgi can be done with the django development server (aka ./manage.py runserver).
Inotify
Here we are getting to the main topic at last. Assuming you have installed inotify-tools you could type this into your shell. You don't need to write a script.
while inotifywait -r -e modify .; do sudo kill -2 yourpid ; done
This will result in the code being reloaded when ...
... using daemon mode with a single process you can send a SIGINT
signal to the daemon process using the ‘kill’ command, or have the
application send the signal to itself when a specific URL is
triggered.
ref: http://modwsgi.readthedocs.io/en/develop/user-guides/frequently-asked-questions.html#application-reloading
alternatively
while inotifywait -r -e modify .; do touch wsgi.py ; done
when
... using daemon mode, with any number of processes, and the process
reload mechanism of mod_wsgi 2.0 has been enabled, then all you need
to do is touch the WSGI script file, thereby updating its modification
time, and the daemon processes will automatically shutdown and restart
the next time they receive a request.
In both situations we are using the -r flag to tell inotify to monitor subdirectories. That means each time you save a .css or .js file apache will reload. But without the -r flag changes to python code in subfolders will be undetected. To have the best of both worls, remove css, js, images etc with the --exclude directive.
What about when your IDE saves an auto backup file? or vim saves the .swp file? That too will cause a code reload. So you would have to exclude those file types too.
So in short, it's a lot of hard work to reproduce what the django development server does free of charge.

You can use inotify hooktables to run any command you want depending on a i-notify signal (here's my source link: http://terokarvinen.com/2016/when-files-change-take-action-inotify-hookable).
After looking the tables you can just reload the code of apache.
For your specific problem, it should be something like:
inotify-hookable --watch-directories sources/ --recursive --on-modify-command './code_reload.sh'
In the previous link, the command to execute was just a simple touch flask/init.wsgi
So, the whole code (adding ignored files was):
inotify-hookable --watch-directories flask/ --recursive --ignore-paths='flask/init.wsgi' --on-modify-command 'touch flask/init.wsgi'
As stated here: Flask + mod_wsgi automatic reload on source code change, if you have enabled WSGIScriptReloading, you can just touch that file. It will cause the entire code to reload (not just the config file). But, if you prefer, you can set any other script to reload the code.
After googling a bit, it seems to be a pretty standard solution for that problem and I think that you can use it for your application.

Pelican restarting you server

Hi I just started working with Pelican and it really suits my needs, I had tried to build blogs in Flask and other frameworks but I really just wanted something simple so I can post about math, and pelican just works.
My question is when I am testing on my machine, I start the server; however when I stop the server to make some edits to my test blogs, and then try to reload the server I get a socket already in use error. I am stopping my server by ctrl+z am I doing this correctly?

Use ctrl+c to terminate the process. ctrl+z will only send it's execution to the background.
On a separate note, since you are making changes and want to test them it would be more convenient to use $ make devserver instead of $ make serve. See docs.

For your development server, you can also use the script ./develop_server.sh that comes with the last versions of pelican (at least with the 3.5.0).
Build the blog and load a server with ./develop_server.sh start: it reloads each time you edit your blog (except the settings). Simply stop with ./develop_server.sh stop when you're finished.

When you press Ctrl + C or Ctrl + z, do not restart the HTTP server: it is running in the background, and that is the exact reason as why you are getting that error message.
To see that the server is running in the background after pressing the any of the key combinations above, try to edit and save any file: you will see right away in the terminal the re-generation process of your pages is active again.
You can start the HTTP server using this command: make devserver and stop by ./developer_server.sh stop

Intermittent "Page Not Found" when using Django through Pydev

I recently started developing Django using Pydev in Eclipse, along with several other people I know, and I keep losing several hours of productivity a day to this error that I can't seem to debug. Essentially, sometimes after starting up my django run configuration, I'll go to the URL http://127.0.0.1:8000/foo and it simply spits me back this response:
<h1>Page not found: /foo</h1>
At first I could reproduce this behavior all the time; any time I had multiple workspaces of eclipse open and shut down my Django server once, the server wouldn't actually shut down, but it would just keep serving the page not founds until I shut down both instances of Eclipse.
Stopping doing that and it seemed to work, but then it intermittently seemed to start back up again. When this happens, it will literally not stop happening until I close eclipse, and the eclipse.exe process will hang (and continue to server Page not found pages) until I manually go into the process and kill it. Sometimes, that won't even fix it, and it'll break itself the first time I try to start Django back up.
I'm on the stable build of PyDev and Eclipse 3.6.1.
Any idea what's going on? This is unbelievable frustrating, especially because I tend to like the IDE with this exception.

Are you by any chance using a run configuration to launch your development server? Because that kept happening to me too. It seems that eclipse isn't cleanly closing django when you stop it from the IDE and it's holding on to the http port. In that sense you're sending requests to a zombie server instance, hence the not founds. I have since resorted to launching django from the command line. Not the prettiest solution, I admit.