We Keep Coding

Instal postgres sql in windows 10

I try to install the latest version of postgres sql using the latest version and the recommended set up.
However when I open the pg adming I receive this error.
Python Path: "C:\Program Files\PostgreSQL\13\pgAdmin 4\python\python.exe"
Runtime Config File: "C:\Users\User\AppData\Roaming\pgadmin\runtime_config.json"
pgAdmin Config File: "C:\Program Files\PostgreSQL\13\pgAdmin 4\web\config.py"
Webapp Path: "C:\Program Files\PostgreSQL\13\pgAdmin 4\web\pgAdmin4.py"
pgAdmin Command: "C:\Program Files\PostgreSQL\13\pgAdmin 4\python\python.exe C:\Program Files\PostgreSQL\13\pgAdmin 4\web\pgAdmin4.py"
Traceback (most recent call last):
File "../web/pgAdmin4.py", line 98, in <module>
app = create_app()
File "C:\Program Files\PostgreSQL\13\pgAdmin 4\web\pgadmin\__init__.py", line 347, in create_app
if not os.path.exists(SQLITE_PATH) or get_version() == -1:
File "C:\Program Files\PostgreSQL\13\pgAdmin 4\web\pgadmin\setup\db_version.py", line 19, in get_version
return version.value
AttributeError: 'NoneType' object has no attribute 'value'
Any help on how to fix it?

After trying all the other suggestions without success, it finally worked for me now, with the way suggested here: Get fatal error: server could not be contacted when running pgAdmin4. 'NoneType' object has no attribute 'value'
Install the newest version of the standalone pgAdmin from https://www.pgadmin.org/download/pgadmin-4-windows/
(you can do the installation additionally to the existing bundled version, without having to remove anything before)
Delete the C:\Users\your_username\AppData\Roaming\pgadmin folder
(I restarted the postgres service once again)
Run the new pgAdmin as Administrator - it works!
Several people report that, from then on, even the old bundled version of pgAdmin works fine!

I resolved in this way:
I removed PGadmin from "Application Stack Builder"
download last version v4 5.2 (pgAdmin 4 v5.2 (released April 22, 2021)
installed...
lunched like admin... (error as usual)
clean-up folder C:\Users\XXXXX\AppData\Roaming\pgadmin (opsssss)
lunched like admin... All ran successfully!
Using all in one PGadmin with Application Stack gave me an usual error bind to some pyton or configuration file
Alen

I had a lot of trouble launching pgAdmin. Several solutions are there.
Try an older version of pgAdmin. The latest version might have unresolved issues.
Go to %APPDATA% (C:\Users{{your username}}\AppData\Roaming) folder and delete the pgadmin folder and run again.
go to environment variables (search environment on search bar) -> advanced, the click on Environment Variables. On System Variables click on path and set a new path for C:\Program Files\PostgreSQL\13\bin (the address might vary on your PC)

ModuleNotFoundError: No module named 'scrapy' (Error happend in PyCharm)

I just create a new project in PyCharm, then try to run the command scrapy startproject filename. Then the error happened.
Traceback (most recent call last):
File "c:\users\管理员\appdata\local\programs\python\python38\lib\runpy.py", line 194, in
_run_module_as_main
return _run_code(code, main_globals, None,
File "c:\users\管理员\appdata\local\programs\python\python38\lib\runpy.py", line 87, in
_run_code
exec(code, run_globals)
File "C:\Users\administrator\AppData\Local\Programs\Python\Python38\Scripts\scrapy.exe\__m
ain__.py", line 4, in <module>
ModuleNotFoundError: No module named 'scrapy'
Before I created this project, I had found that the administrator name was in Simple Chinese. To avoid the further problem in other project, I modify the name from simply Chinese as well and the file name in C://users/管理员 (where I installed the Python) and in the Path in system environment variables.
Does this error happen because of modification of the name? Or is there any other default configuration in PyCharm I need to modify?

After searching from a website named CSDN, I found this method works for my problem. I just briefly describe how I handle that.Hope it will be helpful for other people who meet the similar problem.
The link: https://blog.csdn.net/weixin_39278265/article/details/82938270
I installed the scrapy under C://user/管理员/.../Python38/...
And yesterday after I installed scrapy, I found it doesn't work in Pycharm but, in MS-DOS, it worked. Some people told me the path with UTF-8 characters caused the problem. So I modified the path from UTF-8 characters to English characters.
Then I deleted all the path environmental variables of Python in System and modified the path environmental variables of Python in Users from UTF-8 characters to English Characters.
After that I opened the pip.exe, pip3.exe, scrapy.exe in ...python38/scripts/ by Notepad and modified the path in the same way I did above.
After that I opened the PyCharm then run the command scrapy startproject projectname,it worked as in CMD interface and showed:
You can start your first spider with:
cd sxh01
scrapy genspider example example.com

Python imports wrong version of sqlite when running tests

I'm trying to set up a Windows slave for our Jenkins server, but some of the unit tests are failing due to a sqlite error.
We're using conda and have built a custom version of sqlite that includes rtree. Then our application is built using this custom sqlite. When we install our app on the windows server, the correct version of sqlite is installed:
$ conda list
sqlite 3.16.2 vc9_0 [vc9] file://[package_server]
Running the app from the command line it works as expected. When we run tests though,
$ nosetests test
...
======================================================================
ERROR: test_vectorise_1 (test.system_test_wallet.test_rasters.test_vectorise.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File "farm\rasters\vectorise.py", line 189, in run_vectorise
proc(progressfn)
File "farm\process.py", line 1278, in __call__
for feature in lyr:
File "C:\bin\Miniconda2\envs\farm_system_test_windows\lib\site-packages\osgeo\
ogr.py", line 2876, in next
feature = self.GetNextFeature()
File "C:\bin\Miniconda2\envs\farm_system_test_windows\lib\site-packages\osgeo\
ogr.py", line 1460, in GetNextFeature
return _ogr.Layer_GetNextFeature(self, *args)
RuntimeError: sqlite3_exec(CREATE VIRTUAL TABLE "rtree_GB_TEST_RP100_VE_5m_27700
_geom" USING rtree(id, minx, maxx, miny, maxy)) failed: no such module: rtree
I added some logging to show python executable path and sqlite3 path and it is the same every time, so it's not a virtualenv issue:
C:\bin\Miniconda2\envs\farm_system_test_windows\python.exe
C:\bin\Miniconda2\envs\farm_system_test_windows\lib\sqlite3\__init__.pyc
Printing the sqlite version though, shows some differences:
print('sql ver', sqlite3.sqlite_version_info)
Running the app from the command line, you get (3, 16, 2), which is the correct version. Running nosetests, you get (3, 8, 11) - an older version and presumably the reason for rtree not being found.
Weirdly, if you call a test file with
python path/to/test.py
and let unittest do its stuff, version (3, 16, 2) is initially imported, but then when the test runs, you get (3, 8, 11) and the test errors.
What is going on here? Why do I get a different version of sqlite depending on how I call the application?
I'm using python 2.7.14, conda 4.4.11 on Windows Server 2012 R2.
UPDATE:
I'm still getting this error on Jenkins and now on my dev machine too. It's not just a nose issue, as when I run the test using unittest, I get the error. The PYTHONPATH and sys.path are the same in both cases, and the call stack is identical, except with unittest, there are an extra two frames at the top.
File "C:\ProgramData\Anaconda2\envs\farm\lib\runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "C:\ProgramData\Anaconda2\envs\farm\lib\runpy.py", line 72, in _run_code
exec code in run_globals
Interestingly, the rest of the call stack shows an absolute path for main.py, the entry point, and relative paths for everything else when using unittest. When calling main.py directly however, main.py has a relative path and all the other files have absolute paths.
Does anyone have any idea why we're seeing this difference? It's really frustrating having to skip a load of tests when we're running on windows.

By looking for a solution in sys.path you are looking at the wrong place. You need to see what os.environ['PATH'] is at the critical points here since it's the Windows Loader that has picked the 'wrong' DLL, where by wrong I mean the first one it found according to its well documented DLL lookup procedure.

Syntax Error When Trying to Open Downloaded Django Application

I am trying to work on a Django application that I downloaded from bitbucket which uses Python2-based code. Previously, Python 3.6 and Django 2.0 was on my system, so I downgraded to Python 2.7 and Django 1.11 to try to get it to work.
When I go to the project directory and type in "python manage.py runserver," I get a syntax error (this is a shortened version of it, hence the dots):
Unhandled exception in thread started by <function wrapper at 0x0000000006A0A358>
Traceback (most recent call last):
File "C:\Users\M\Anaconda3\lib\site-packages\django\utils\autoreload.py", line 227, in wrapper
fn(*args, **kwargs)
.
.
.
File "C:\Users\M\Anaconda3\lib\site-packages\django\contrib\admindocs\urls.py", line 2, in <module>
from django.contrib.admindocs import views
File "C:\Users\M\Anaconda3\lib\site-packages\django\contrib\admindocs\views.py", line 9, in <module>
from django.contrib.admindocs import utils
File "C:\Users\M\Anaconda3\lib\site-packages\django\contrib\admindocs\utils.py", line 12, in <module>
import docutils.core
File "C:\Users\M\Anaconda3\lib\site-packages\docutils\core.py", line 246
print('\n::: Runtime settings:', file=self._stderr)
^
SyntaxError: invalid syntax
If you have a solution to this problem, please let me know.

As said by #emi, you want to use virtualenv. It's a great tool that allows you to create an isolated virtual environment for each Python project. Each virtual environment can have its own version of every dependency.
On Windows, I recommend using it alongside virtualenvwrapper, witch is is just a very thin wrapper with some higher level commands.
It seems your Python installation is broken so uninstall every version of Python you have, reinstall Python 2 and follow along creating a virtualenv for your project (and for every new one you start). If you need you can install Python 3 in the future as well without messing with you previous envs.

Python import error on Windows: no __path__

OK, trying to track down this issue of running a Python package.
Running on Windows.
Only one version of Python is installed on the computer: 3.4.3
Package has been installed (package name: Willie) (details of installation are more convoluted than usual; can provide steps if necessary)
Package installed at: C:\Python34\Lib\site-packages\willie
Startup script is: C:\Python34\Scripts\willie.py
Error is one of the first lines of the script:
from willie.tools import stderr
If I run willie.py from the command line, I get this error:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 2218, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python34\Scripts\willie.py", line 15, in <module>
from willie.tools import stderr
File "C:\Python34\Scripts\willie.py", line 15, in <module>
from willie.tools import stderr
ImportError: No module named 'willie.tools'; 'willie' is not a package
The __path__ attribute is supposed to be set automatically when the import function is used, but it doesn't exist, which leads to the program being unable to execute.
C:\Python34\Scripts; is in my Path environment variable.
PYTHONPATH has been set for everything from C:\Python34; to C:\Python34;C:\Python34\Lib;C:\Python34\Lib\site-packages;C:\Python34\Lib\site-packages;C:\Python34\Lib\site-packages\willie;C:\Python34\Lib\site-packages\willie\tools;.
In all cases with these directories, if I try to execute the above import command from the interactive Python prompt, it runs correctly. I can use the stderr function, and examine its __file__ and __path__ fields.
If I add C:\Python34\Scripts; to PYTHONPATH, however, I get the same error as using it from the command line: __path__ doesn't exist, 'willie' is not a package.
I do know that willie.py is being called recursively, somehow, because I can add a print() at the top of the file that runs twice.
Looking for help in figuring out how to make this run. Is almost certainly a configuration issue on my end, but I have no idea what to do to fix it.

First, you absolutely do not want c:\Python34\Scripts in your PYTHONPATH. Files under \Scripts are NOT meant to be importable.
Second, willie does some screwing around to make sure willie.py gets installed to c:\Python34\Scripts\willie (note there is no .py suffix). This is decidedly nonstandard. The only reason this even works is because on Unix machines, the first line of that file is a special "shebang" that tells the Unix program launcher to execute the file using Python. There is no equivalent feature on Windows - naming the file willie with no .py means you simply can't execute it.
So it looks like the module willie is simply not prepared to be installed on Windows systems. (#811 and #822 both refer to weirdness on Windows caused by the nonstandard package setup.)
A standard package setup would have willie.py inside the willie package as willie/main.py and, in the package's setup.py, register willie.main as an "Entry Point" named willie. This incantation would create c:\Python34\Scripts\willie.exe on Windows systems when the package is installed using pip.
I believe the reason for the recursive import is because the second entry in sys.path is the name of the script that is run from the command line. So, it's always finding C:\Python34\Scripts\willie.py when it looks for the module willie which is not the one it needs.
As a workaround, you could try renaming C:\Python34\Scripts\willie.py to C:\Python34\Scripts\run-willie.py