Exception trying to install pgadmin4 version 8.4

[Shaheed Haque]

Hi,

I have a scripted install for pgadmin4 which worked as expected for
pgadmin7.7 when last used. I'm now trying to install 8.4 in a new VM, and
it fails like this:

$ sudo -i -u ubuntu PGADMIN_SETUP_EMAIL=x...@123.com
PGADMIN_SETUP_PASSWORD=abcd python3
/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py setup-db
2024-03-10 03:13:21,163: ERROR  pgadmin:Database migration failed
2024-03-10 03:13:21,164: ERROR  pgadmin:Traceback (most recent call
last):
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
line 386, in upgrade_db
   db_upgrade(app)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/setup/db_upgrade.py",
line 22, in db_upgrade
   flask_migrate.upgrade(migration_folder)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 111, in wrapped
   f(*args, **kwargs)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 198, in upgrade
   config = current_app.extensions['migrate'].migrate.get_config(directory,
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 96, in get_config
   for x in g.x_arg:
 File "/home/ubuntu/venv/lib/python3.10/site-packages/flask/ctx.py", line
54, in __getattr__
   raise AttributeError(name) from None
AttributeError: x_arg
...
ascii art traceback
...
AttributeError: x_arg

During handling of the above exception, another exception occurred:
...
ascii art traceback
...
FileNotFoundError: [Errno 2] No such file or directory:
'/var/lib/pgadmin/pgadmin4.db' ->
'/var/lib/pgadmin/pgadmin4.db.20240310031321'

Note: the argument "setup-db" was not previously used, but seems required
now. I've enclosed the output of "pip freeze" below. I have verified that
the directory "/var/lib/pgadmin" exists, and is writeable by the user
"ubuntu". In the same directory as setup.py is the following file:

$ cat
/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/config_local.py
LOG_FILE = '/var/log/pgadmin/pgadmin4.log'
SQLITE_PATH = '/var/lib/pgadmin/pgadmin4.db'
SESSION_DB_PATH = '/var/lib/pgadmin/sessions'
STORAGE_DIR = '/var/lib/pgadmin/storage'
AZURE_CREDENTIAL_CACHE_DIR = '/var/lib/pgadmin/azurecredentialcache'
  <<< new entry
KERBEROS_CCACHE_DIR = '/var/lib/pgadmin/kerberoscache'
  <<< new entry
SERVER_MODE = True

Note: I have highlighted a couple of entries which I added after reading
the current installation documentation. I also tried launching the VM with
the previously working pgadmin4 7.7

$ sudo -i -u ubuntu PGADMIN_SETUP_EMAIL=1...@123.com
PGADMIN_SETUP_PASSWORD=abcdedg python3
/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py setup-db
2024-03-10 10:04:24,371: ERROR  pgadmin:Database migration failed
2024-03-10 10:04:24,372: ERROR  pgadmin:Traceback (most recent call
last):
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
line 390, in upgrade_db
   db_upgrade(app)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/setup/db_upgrade.py",
line 25, in db_upgrade
   flask_migrate.upgrade(migration_folder)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 111, in wrapped
   f(*args, **kwargs)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 198, in upgrade
   config = current_app.extensions['migrate'].migrate.get_config(directory,
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 96, in get_config
   for x in g.x_arg:
 File "/home/ubuntu/venv/lib/python3.10/site-packages/flask/ctx.py", line
52, in __getattr__
   raise AttributeError(name) from None
AttributeError: x_arg
Traceback (most recent call last):
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
line 390, in upgrade_db
   db_upgrade(app)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/setup/db_upgrade.py",
line 25, in db_upgrade
   flask_migrate.upgrade(migration_folder)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 111, in wrapped
   f(*args, **kwargs)
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 198, in upgrade
   config = current_app.extensions['migrate'].migrate.get_config(directory,
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
line 96, in get_config
   for x in g.x_arg:
 File "/home/ubuntu/venv/lib/python3.10/site-packages/flask/ctx.py", line
52, in __getattr__
   raise AttributeError(name) from None
AttributeError: x_arg
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py",
line 220, in 
   app = create_app()
 File
"/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
line 477, in create_app
   run_migration_for_sqlite()
 

Re: Exception trying to install pgadmin4 version 8.4

[Shaheed Haque]

OK, it looks as though this problem occurs newly in flask-migrate 4.0.6. It
looks as though the changes here:

https://github.com/miguelgrinberg/Flask-Migrate/commit/6f3f889c36030134f87dc1db327c2385d873a4d6

introduce some new behaviour which I guess pgadmin4 does not yet support.
Can I gently request that the pgadmin4 team look into this further? I am of
course happy to test as needed.

Thanks, Shaheed

On Sun, 10 Mar 2024 at 10:56, Shaheed Haque  wrote:

> Hi,
>
> I have a scripted install for pgadmin4 which worked as expected for
> pgadmin7.7 when last used. I'm now trying to install 8.4 in a new VM, and
> it fails like this:
>
> $ sudo -i -u ubuntu PGADMIN_SETUP_EMAIL=x...@123.com
> PGADMIN_SETUP_PASSWORD=abcd python3
> /home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py setup-db
> 2024-03-10 03:13:21,163: ERROR  pgadmin:Database migration failed
> 2024-03-10 03:13:21,164: ERROR  pgadmin:Traceback (most recent
> call last):
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
> line 386, in upgrade_db
>db_upgrade(app)
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/setup/db_upgrade.py",
> line 22, in db_upgrade
>flask_migrate.upgrade(migration_folder)
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
> line 111, in wrapped
>f(*args, **kwargs)
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
> line 198, in upgrade
>config = current_app.extensions['migrate'].migrate.get_config(directory,
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
> line 96, in get_config
>for x in g.x_arg:
>  File "/home/ubuntu/venv/lib/python3.10/site-packages/flask/ctx.py", line
> 54, in __getattr__
>raise AttributeError(name) from None
> AttributeError: x_arg
> ...
> ascii art traceback
> ...
> AttributeError: x_arg
>
> During handling of the above exception, another exception occurred:
> ...
> ascii art traceback
> ...
> FileNotFoundError: [Errno 2] No such file or directory:
> '/var/lib/pgadmin/pgadmin4.db' ->
> '/var/lib/pgadmin/pgadmin4.db.20240310031321'
>
> Note: the argument "setup-db" was not previously used, but seems required
> now. I've enclosed the output of "pip freeze" below. I have verified that
> the directory "/var/lib/pgadmin" exists, and is writeable by the user
> "ubuntu". In the same directory as setup.py is the following file:
>
> $ cat
> /home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/config_local.py
> LOG_FILE = '/var/log/pgadmin/pgadmin4.log'
> SQLITE_PATH = '/var/lib/pgadmin/pgadmin4.db'
> SESSION_DB_PATH = '/var/lib/pgadmin/sessions'
> STORAGE_DIR = '/var/lib/pgadmin/storage'
> AZURE_CREDENTIAL_CACHE_DIR = '/var/lib/pgadmin/azurecredentialcache'
>   <<< new entry
> KERBEROS_CCACHE_DIR = '/var/lib/pgadmin/kerberoscache'
>   <<< new entry
> SERVER_MODE = True
>
> Note: I have highlighted a couple of entries which I added after reading
> the current installation documentation. I also tried launching the VM with
> the previously working pgadmin4 7.7
>
> $ sudo -i -u ubuntu PGADMIN_SETUP_EMAIL=1...@123.com
> PGADMIN_SETUP_PASSWORD=abcdedg python3
> /home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py setup-db
> 2024-03-10 10:04:24,371: ERROR  pgadmin:Database migration failed
> 2024-03-10 10:04:24,372: ERROR  pgadmin:Traceback (most recent
> call last):
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
> line 390, in upgrade_db
>db_upgrade(app)
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/setup/db_upgrade.py",
> line 25, in db_upgrade
>flask_migrate.upgrade(migration_folder)
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
> line 111, in wrapped
>f(*args, **kwargs)
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
> line 198, in upgrade
>config = current_app.extensions['migrate'].migrate.get_config(directory,
>  File
> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
> line 96, in get_config
>for x in g.x_arg:
>  File "/home/ubuntu/venv/lib/python3.10/site-packages/flask/ctx.py", line
> 52, in __getattr__
>raise AttributeError(name) from None
> AttributeError: x_arg
&g

Re: Exception trying to install pgadmin4 version 8.4

[Shaheed Haque]

Added to existing issue
https://github.com/pgadmin-org/pgadmin4/issues/7266#issuecomment-1987956752.
..

On Mon, 11 Mar 2024 at 03:17, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Sun, Mar 10, 2024 at 7:06 PM Shaheed Haque 
> wrote:
>
>> OK, it looks as though this problem occurs newly in flask-migrate 4.0.6.
>> It looks as though the changes here:
>>
>>
>> https://github.com/miguelgrinberg/Flask-Migrate/commit/6f3f889c36030134f87dc1db327c2385d873a4d6
>>
>> introduce some new behaviour which I guess pgadmin4 does not yet support.
>> Can I gently request that the pgadmin4 team look into this further? I am of
>> course happy to test as needed.
>>
>> Please log a request @ https://github.com/pgadmin-org/pgadmin4/issues
>
>> Thanks, Shaheed
>>
>> On Sun, 10 Mar 2024 at 10:56, Shaheed Haque 
>> wrote:
>>
>>> Hi,
>>>
>>> I have a scripted install for pgadmin4 which worked as expected for
>>> pgadmin7.7 when last used. I'm now trying to install 8.4 in a new VM, and
>>> it fails like this:
>>>
>>> $ sudo -i -u ubuntu PGADMIN_SETUP_EMAIL=x...@123.com
>>> PGADMIN_SETUP_PASSWORD=abcd python3
>>> /home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py setup-db
>>> 2024-03-10 03:13:21,163: ERROR  pgadmin:Database migration failed
>>> 2024-03-10 03:13:21,164: ERROR  pgadmin:Traceback (most recent
>>> call last):
>>>  File
>>> "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/__init__.py",
>>> line 386, in upgrade_db
>>>db_upgrade(app)
>>>  File
>>> "/home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/pgadmin/setup/db_upgrade.py",
>>> line 22, in db_upgrade
>>>flask_migrate.upgrade(migration_folder)
>>>  File
>>> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
>>> line 111, in wrapped
>>>f(*args, **kwargs)
>>>  File
>>> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
>>> line 198, in upgrade
>>>config =
>>> current_app.extensions['migrate'].migrate.get_config(directory,
>>>  File
>>> "/home/ubuntu/venv/lib/python3.10/site-packages/flask_migrate/__init__.py",
>>> line 96, in get_config
>>>for x in g.x_arg:
>>>  File "/home/ubuntu/venv/lib/python3.10/site-packages/flask/ctx.py",
>>> line 54, in __getattr__
>>>raise AttributeError(name) from None
>>> AttributeError: x_arg
>>> ...
>>> ascii art traceback
>>> ...
>>> AttributeError: x_arg
>>>
>>> During handling of the above exception, another exception occurred:
>>> ...
>>> ascii art traceback
>>> ...
>>> FileNotFoundError: [Errno 2] No such file or directory:
>>> '/var/lib/pgadmin/pgadmin4.db' ->
>>> '/var/lib/pgadmin/pgadmin4.db.20240310031321'
>>>
>>> Note: the argument "setup-db" was not previously used, but seems
>>> required now. I've enclosed the output of "pip freeze" below. I have
>>> verified that the directory "/var/lib/pgadmin" exists, and is writeable by
>>> the user "ubuntu". In the same directory as setup.py is the following file:
>>>
>>> $ cat
>>> /home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/config_local.py
>>> LOG_FILE = '/var/log/pgadmin/pgadmin4.log'
>>> SQLITE_PATH = '/var/lib/pgadmin/pgadmin4.db'
>>> SESSION_DB_PATH = '/var/lib/pgadmin/sessions'
>>> STORAGE_DIR = '/var/lib/pgadmin/storage'
>>> AZURE_CREDENTIAL_CACHE_DIR = '/var/lib/pgadmin/azurecredentialcache'
>>> <<< new entry
>>> KERBEROS_CCACHE_DIR = '/var/lib/pgadmin/kerberoscache'
>>> <<< new entry
>>> SERVER_MODE = True
>>>
>>> Note: I have highlighted a couple of entries which I added after reading
>>> the current installation documentation. I also tried launching the VM with
>>> the previously working pgadmin4 7.7
>>>
>>> $ sudo -i -u ubuntu PGADMIN_SETUP_EMAIL=1...@123.com
>>> PGADMIN_SETUP_PASSWORD=abcdedg python3
>>> /home/ubuntu/venv/lib/python3.10/site-packages/pgadmin4/setup.py setup-db
>>> 2024-03-10 10:04:24,371: ERROR  pgadmin:Database migration failed
>>> 2024-03-10 10:04:24,372: ERROR  pgadmin:Trace

Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

Hi,

I'm a relative noob when it comes to the world of nginx, wsgi and so forth,
but I do have several other things working (a Django app under gunicorn and
the RabbitMQ web UI directly behind nginx). However, I'm rather stuck
getting pgAdmin4 to run at http://mydomain.com:80/pgadmin behind nginx. Is
there a simple, up-to-date example of how to do this (I'm running the
latest, v4.2, of pgAdmin4)?

I'm aware of threads such as
https://www.postgresql.org/message-id/2197768425D7F5479A0FFB3FEC212F7FF602B871%40aesmail.surcouf.local,
and several others but not been able to come up with a clear approach:

One of the several variables I'm struggling to understand is the choice of
whether to run pgAdmin4.py on port 5050 directly behind nginx, or as a WSGI
app under gunicorn. I assume the latter should be easier to set up, but
I've tried both (modelled on what I have working, and various references).
One combination I tried was:

- Creating a softlink from pgadmin4.py to pgAdmin4.wsgi
- Using gunicorn to run the pgadmin4.py to a unix domain socket like this:

$ /usr/local/bin/gunicorn -w 1 --bind unix:/home/ubuntu/pgadmin.sock
pgadmin4:application

- Serving behind nginx like this:

location /pgadmin {
rewrite ^/pgadmin/(.*) /$1 break;
include proxy_params;
proxy_pass http://unix:/home/ubuntu/pgadmin.sock;
}

But all I get is a stubborn 404. Any pointers welcome...

Thanks, Shaheed

P.S. I considered just making pgAdmin4.py listen on 0.0.0.0:5050, but I do
need to get everything behind HTTPS sooner rather than later.

Scripted addition of servers?

[Shaheed Haque]

Elsewhere [1], I mentioned that I have pgAdmin running in server mode
behind nginx and gunicorn in an embedded role, to provide admin access to a
pre-determined set of servers.

As part of that, the initial user is pre-configured programmatically like
this:

PGADMIN_SETUP_EMAIL=$SUPERUSER PGADMIN_SETUP_PASSWORD=$PW python3
.../setup.py

Is it possible to programatically set up servers? At a minimum, I'd guess
I'd need to specify the server name, the username and password for each
server.

Thanks, Shaheed

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

OK, I got it working. This is how...

On Mon, 25 Feb 2019 at 23:25, Shaheed Haque  wrote:
>
> Hi,
>
> I'm a relative noob when it comes to the world of nginx, wsgi and so
forth, but I do have several other things working (a Django app under
gunicorn and the RabbitMQ web UI directly behind nginx). However, I'm
rather stuck getting pgAdmin4 to run at http://mydomain.com:80/pgadmin
behind nginx. Is there a simple, up-to-date example of how to do this (I'm
running the latest, v4.2, of pgAdmin4)?
>
> I'm aware of threads such as
https://www.postgresql.org/message-id/2197768425D7F5479A0FFB3FEC212F7FF602B871%40aesmail.surcouf.local,
and several others but not been able to come up with a clear approach:
>
> One of the several variables I'm struggling to understand is the choice
of whether to run pgAdmin4.py on port 5050 directly behind nginx, or as a
WSGI app under gunicorn. I assume the latter should be easier to set up,
but I've tried both (modelled on what I have working, and various
references). One combination I tried was:
>
> - Creating a softlink from pgadmin4.py to pgAdmin4.wsgi
> - Using gunicorn to run the pgadmin4.py to a unix domain socket like this:
>
> $ /usr/local/bin/gunicorn -w 1 --bind unix:/home/ubuntu/pgadmin.sock
pgadmin4:application
>
> - Serving behind nginx like this:
>
> location /pgadmin {
> rewrite ^/pgadmin/(.*) /$1 break;
> include proxy_params;
> proxy_pass http://unix:/home/ubuntu/pgadmin.sock;
> }
>
> But all I get is a stubborn 404. Any pointers welcome...

First, I got over the 404s (caused, it seems, by me forgetting just how
much my browser had cached :-0). The next problem was with the nginx config
fragment: as soon as pgAdmin responded, it of course started the browser
looking for top level URLs such as /browser and /static which are obviously
not under /pgadmin. The to this key was a piece of code in
https://stackoverflow.com/a/50515636/6332554, which basically adds the
concept of a SCRIPT_NAME by hacking a small wodge of code into pgAdmin4.py.

The SCRIPT_NAME is set by an nginx fragment like this:

location /pgadmin {
rewrite ^/pgadmin/(.*)$ /\$1 break;
include proxy_params;
proxy_pass http://unix:/home/$CLOUD_USER/pgadmin.sock;
proxy_set_header X-Script-Name /pgadmin;
}

In addition to that change, as previously noted, I needed to create a link
to pgAdmin4.wsgi to allow gunicorn to pick it up. I change the name I used
so I ended up with the link being "wsgi.py" -> "pgAdmin4.py", so the the
corresponding gunicorn command is something like this:

gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application

Now, IIUC, the notion of SCRIPT_NAME is somewhat standard, and needed to
solve this issue of running pgAdmin in server mode, but sharing the domain
with other applications. Would there be interest in making the needed code
an integral part of pgAdmin? If so, I'd be happy to file a feature request.

Thanks, Shaheed

Re: Scripted addition of servers?

[Shaheed Haque]

On Fri, 1 Mar 2019 at 09:40, Dave Page  wrote:

> Hi
>
> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque  wrote:
>
>> Elsewhere [1], I mentioned that I have pgAdmin running in server mode
>> behind nginx and gunicorn in an embedded role, to provide admin access to a
>> pre-determined set of servers.
>>
>> As part of that, the initial user is pre-configured programmatically like
>> this:
>>
>> PGADMIN_SETUP_EMAIL=$SUPERUSER PGADMIN_SETUP_PASSWORD=$PW python3 
>> .../setup.py
>>
>> Is it possible to programatically set up servers? At a minimum, I'd guess
>> I'd need to specify the server name, the username and password for each
>> server.
>>
>
> Yes. See
> https://www.pgadmin.org/docs/pgadmin4/4.x/export_import_servers.html.
>

Perfect, thanks for the quick reply. Apologies for not having consulted the
docs first.

Shaheed


> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

Dave,

Thanks for taking this forward, I look forward to 4.4! I also noted with
interest that we can use "pgAdmin4:app" rather than my hacky link to the
pgAdmin4.wsgi, so that means a completely hack-free solution :-).


Shaheed

On Mon, 4 Mar 2019 at 16:33, Dave Page  wrote:

> Hi
>
> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque  wrote:
>
>> OK, I got it working. This is how...
>>
>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque  wrote:
>> >
>> > Hi,
>> >
>> > I'm a relative noob when it comes to the world of nginx, wsgi and so
>> forth, but I do have several other things working (a Django app under
>> gunicorn and the RabbitMQ web UI directly behind nginx). However, I'm
>> rather stuck getting pgAdmin4 to run at http://mydomain.com:80/pgadmin
>> behind nginx. Is there a simple, up-to-date example of how to do this (I'm
>> running the latest, v4.2, of pgAdmin4)?
>> >
>> > I'm aware of threads such as
>> https://www.postgresql.org/message-id/2197768425D7F5479A0FFB3FEC212F7FF602B871%40aesmail.surcouf.local,
>> and several others but not been able to come up with a clear approach:
>> >
>> > One of the several variables I'm struggling to understand is the choice
>> of whether to run pgAdmin4.py on port 5050 directly behind nginx, or as a
>> WSGI app under gunicorn. I assume the latter should be easier to set up,
>> but I've tried both (modelled on what I have working, and various
>> references). One combination I tried was:
>> >
>> > - Creating a softlink from pgadmin4.py to pgAdmin4.wsgi
>> > - Using gunicorn to run the pgadmin4.py to a unix domain socket like
>> this:
>> >
>> > $ /usr/local/bin/gunicorn -w 1 --bind
>> unix:/home/ubuntu/pgadmin.sock pgadmin4:application
>> >
>> > - Serving behind nginx like this:
>> >
>> > location /pgadmin {
>> > rewrite ^/pgadmin/(.*) /$1 break;
>> > include proxy_params;
>> > proxy_pass http://unix:/home/ubuntu/pgadmin.sock;
>> > }
>> >
>> > But all I get is a stubborn 404. Any pointers welcome...
>>
>> First, I got over the 404s (caused, it seems, by me forgetting just how
>> much my browser had cached :-0). The next problem was with the nginx config
>> fragment: as soon as pgAdmin responded, it of course started the browser
>> looking for top level URLs such as /browser and /static which are obviously
>> not under /pgadmin. The to this key was a piece of code in
>> https://stackoverflow.com/a/50515636/6332554, which basically adds the
>> concept of a SCRIPT_NAME by hacking a small wodge of code into pgAdmin4.py.
>>
>> The SCRIPT_NAME is set by an nginx fragment like this:
>>
>> location /pgadmin {
>> rewrite ^/pgadmin/(.*)$ /\$1 break;
>> include proxy_params;
>> proxy_pass http://unix:/home/$CLOUD_USER/pgadmin.sock;
>> proxy_set_header X-Script-Name /pgadmin;
>> }
>>
>> In addition to that change, as previously noted, I needed to create a
>> link to pgAdmin4.wsgi to allow gunicorn to pick it up. I change the name I
>> used so I ended up with the link being "wsgi.py" -> "pgAdmin4.py", so the
>> the corresponding gunicorn command is something like this:
>>
>> gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
>>
>> Now, IIUC, the notion of SCRIPT_NAME is somewhat standard, and needed to
>> solve this issue of running pgAdmin in server mode, but sharing the domain
>> with other applications. Would there be interest in making the needed code
>> an integral part of pgAdmin? If so, I'd be happy to file a feature request.
>>
>> Thanks, Shaheed
>>
>
> Thanks for your work on this.
>
> I've committed a change to add the reverse proxy code, and to put some
> more examples in the docs:
> https://redmine.postgresql.org/projects/pgadmin4/repository/revisions/f401def044c8b47974d58c71ff9e6f71f34ef41d
>
> FWIW, I think the reason that this was an issue for so long is that you
> don't need the extra code if you use mod_wsgi or uWSGI - it's only needed
> with Gunicorn. I'll let you guess which of those technologies I'm most
> familiar with!
>
> Unfortunately this commit won't make the 4.3 release later this week, but
> it will be in 4.4. The instructions will still be good for scenarios other
> than Gunicorn in a sub-directory though.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

4.3 went on a diet?

[Shaheed Haque]

Hi,

I don't mean to look a gift horse in the mouth, but I noticed that whereas
4.1 and 4.2 weighed in at nearly 80MB, the 4.3 wheel is just over 50MB in
size. Is that deliberate?

Thanks, Shaheed

Re: 4.3 went on a diet?

[Shaheed Haque]

On Mon, 11 Mar 2019, 10:40 Dave Page,  wrote:

>
>
> On Fri, Mar 8, 2019 at 7:12 PM Shaheed Haque  wrote:
>
>> Hi,
>>
>> I don't mean to look a gift horse in the mouth, but I noticed that
>> whereas 4.1 and 4.2 weighed in at nearly 80MB, the 4.3 wheel is just over
>> 50MB in size. Is that deliberate?
>>
>
> Most likely because we updated all the screenshots in the docs to match
> the new UI (over 300 of them iirc).
>

Cool...thanks for checking.

-- 
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Noisy dependency on psycopg2 versus psycopg2-binary

[Shaheed Haque]

Hi,

I'm still on 4.2, but checking the release notes for 4.3 suggests it too
has the problem of being dependent on psycopg2 versus psycopg2-binary. This
results in the annoying message:

/usr/local/lib/python3.6/dist-packages/psycopg2/__init__.py:144:
> UserWarning: The psycopg2 wheel package will be renamed from release 2.8;
> in order to keep installing from binary please use "pip install
> psycopg2-binary" instead. For details see: <
> http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
>

My package also had this problem, and the fix was to replace the reference
to psycopg2 with  psycopg2-binary in setup.py. I hope that helps,

Thanks, Shaheed

Re: Noisy dependency on psycopg2 versus psycopg2-binary

[Shaheed Haque]

On Tue, 19 Mar 2019 at 10:28, Dave Page  wrote:

> Hi
>
> On Tue, Mar 19, 2019 at 10:19 AM Shaheed Haque  wrote:
>
>> Hi,
>>
>> I'm still on 4.2, but checking the release notes for 4.3 suggests it too
>> has the problem of being dependent on psycopg2 versus psycopg2-binary. This
>> results in the annoying message:
>>
>> /usr/local/lib/python3.6/dist-packages/psycopg2/__init__.py:144:
>>> UserWarning: The psycopg2 wheel package will be renamed from release 2.8;
>>> in order to keep installing from binary please use "pip install
>>> psycopg2-binary" instead. For details see: <
>>> http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
>>>
>>
>> My package also had this problem, and the fix was to replace the
>> reference to psycopg2 with  psycopg2-binary in setup.py. I hope that helps,
>>
>
> This is not a problem for us - it's completely intentional. We need full
> control over the build of psycopg2, so we can ensure that it, and the
> libpq, OpenSSL, Gettext and other dependent libraries as well as our
> runtime and Python build are all using the same compiler and compiler flags
> etc.
>

That makes sense.


> If there's a way that we could conditionally use psycopg2-binary *just*
> for the wheel, I'd be open to that, but I'm not sure how we could do it.
>

OK, I can see that might be tricky. What, if anything, can I as an end-user
(i.e. someone wanting as little in the way of source builds as possible
:-)) do to avoid the warning? For example, if I were to "pip3 install
--upgrade psycopg2-binary" after the install of pgadmin4, would that be a
reasonable/supported thing to do to get rid of the warning? Or would I end
up with some horrendous/confusing mess?

Thanks, Shaheed

P.S. I should perhaps explain that we have quite a few Bash and Python
scripts that end up indirectly importing the package, and thus our log
files are sprinkled with these messages...





>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Noisy dependency on psycopg2 versus psycopg2-binary

[Shaheed Haque]

My goodness...

On Wed, 20 Mar 2019 at 09:18, Dave Page  wrote:

> Hi
>
> On Wed, Mar 20, 2019 at 6:18 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Tue, Mar 19, 2019 at 10:24 PM Dave Page  wrote:
>>
>>>
>>>
>>> On Tue, Mar 19, 2019 at 1:37 PM Shaheed Haque 
>>> wrote:
>>>
>>>> On Tue, 19 Mar 2019 at 10:28, Dave Page  wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Tue, Mar 19, 2019 at 10:19 AM Shaheed Haque 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm still on 4.2, but checking the release notes for 4.3 suggests it
>>>>>> too has the problem of being dependent on psycopg2 versus 
>>>>>> psycopg2-binary.
>>>>>> This results in the annoying message:
>>>>>>
>>>>>> /usr/local/lib/python3.6/dist-packages/psycopg2/__init__.py:144:
>>>>>>> UserWarning: The psycopg2 wheel package will be renamed from release 
>>>>>>> 2.8;
>>>>>>> in order to keep installing from binary please use "pip install
>>>>>>> psycopg2-binary" instead. For details see: <
>>>>>>> http://initd.org/psycopg/docs/install.html#binary-install-from-pypi
>>>>>>> >.
>>>>>>>
>>>>>>
>>>>>> My package also had this problem, and the fix was to replace the
>>>>>> reference to psycopg2 with  psycopg2-binary in setup.py. I hope that 
>>>>>> helps,
>>>>>>
>>>>>
>>>>> This is not a problem for us - it's completely intentional. We need
>>>>> full control over the build of psycopg2, so we can ensure that it, and the
>>>>> libpq, OpenSSL, Gettext and other dependent libraries as well as our
>>>>> runtime and Python build are all using the same compiler and compiler 
>>>>> flags
>>>>> etc.
>>>>>
>>>>
>>>> That makes sense.
>>>>
>>>>
>>>>> If there's a way that we could conditionally use psycopg2-binary
>>>>> *just* for the wheel, I'd be open to that, but I'm not sure how we could 
>>>>> do
>>>>> it.
>>>>>
>>>>
>>>> OK, I can see that might be tricky. What, if anything, can I as an
>>>> end-user (i.e. someone wanting as little in the way of source builds as
>>>> possible :-)) do to avoid the warning? For example, if I were to "pip3
>>>> install --upgrade psycopg2-binary" after the install of pgadmin4, would
>>>> that be a reasonable/supported thing to do to get rid of the warning? Or
>>>> would I end up with some horrendous/confusing mess?
>>>>
>>>> Thanks, Shaheed
>>>>
>>>> P.S. I should perhaps explain that we have quite a few Bash and Python
>>>> scripts that end up indirectly importing the package, and thus our log
>>>> files are sprinkled with these messages...
>>>>
>>>
>>> I had a brainwave. Aditya, Khushboo - do you see any reason why we
>>> couldn't do the attached?
>>>
>>  After the release of psycopg2 v2.8, the psycopg2 will not contain the
>> binary packages (only psycopg2-binary will), this means, we are going to
>> stick with this solution for the python wheel even after psycopg2 v2.8, Is
>> this correct?
>> If so, then is there any possibility, we may face some problem mentioned
>> in  https://github.com/psycopg/psycopg2/issues/674 for SQLAlchemy?
>>
>
>  Urgh - I hadn't realised the issue was so complex. Right now I'm thinking
> the safest option is to just leave things as they are. It seems like
> psycopg2-binary may work for some users, but not others.
>

Neither had I (@Khushboo thanks for the pointer). I had interpreted the
warning as "you need to stop using psycopg2 and move to psycopg2-binary"
but now I see that opens me up to potential functional issues as well as
pip dependency clashes.

I suspect I probably need to go back to using psycopg2, and get even more
of these confusing/scary warnings. What a mess...

Thanks, Shaheed


> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Noisy dependency on psycopg2 versus psycopg2-binary

[Shaheed Haque]

Dave, Khushboo,

Just to be clear, I'm expecting to install multiple packages which depend
on Python access to PostgreSQL, of which pgAdmin is one. So I would ask
that any solution be clear as to what an end user needs to do to ensure the
various packages can co-exist. I'm more or less happy to assume that the
versions won't drift uncontrollably, but if two different builds of the
same version are needed then any proposed solution needs to address that
please.

I hope that sounds sane.

Thanks, Shaheed

On Wed, 20 Mar 2019 at 12:32, Dave Page  wrote:

>
>
> On Wed, Mar 20, 2019 at 12:21 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 5:49 PM Dave Page  wrote:
>>
>>>
>>>
>>> On Wed, Mar 20, 2019 at 12:11 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 4:54 PM Dave Page  wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Wed, Mar 20, 2019 at 9:50 AM Shaheed Haque 
>>>>> wrote:
>>>>>
>>>>>> My goodness...
>>>>>>
>>>>>
>>>>> Indeed.
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, 20 Mar 2019 at 09:18, Dave Page  wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Wed, Mar 20, 2019 at 6:18 AM Khushboo Vashi <
>>>>>>> khushboo.va...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 19, 2019 at 10:24 PM Dave Page 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 19, 2019 at 1:37 PM Shaheed Haque 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, 19 Mar 2019 at 10:28, Dave Page 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 19, 2019 at 10:19 AM Shaheed Haque <
>>>>>>>>>>> srha...@theiet.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm still on 4.2, but checking the release notes for 4.3
>>>>>>>>>>>> suggests it too has the problem of being dependent on psycopg2 
>>>>>>>>>>>> versus
>>>>>>>>>>>> psycopg2-binary. This results in the annoying message:
>>>>>>>>>>>>
>>>>>>>>>>>> /usr/local/lib/python3.6/dist-packages/psycopg2/__init__.py:144:
>>>>>>>>>>>>> UserWarning: The psycopg2 wheel package will be renamed from 
>>>>>>>>>>>>> release 2.8;
>>>>>>>>>>>>> in order to keep installing from binary please use "pip install
>>>>>>>>>>>>> psycopg2-binary" instead. For details see: <
>>>>>>>>>>>>> http://initd.org/psycopg/docs/install.html#binary-install-from-pypi
>>>>>>>>>>>>> >.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My package also had this problem, and the fix was to replace
>>>>>>>>>>>> the reference to psycopg2 with  psycopg2-binary in setup.py. I 
>>>>>>>>>>>> hope that
>>>>>>>>>>>> helps,
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is not a problem for us - it's completely intentional. We
>>>>>>>>>>> need full control over the build of psycopg2, so we can ensure that 
>>>>>>>>>>> it, and
>>>>>>>>>>> the libpq, OpenSSL, Gettext and other dependent libraries as well 
>>>>>>>>>>> as our
>>>>>>>>>>> runtime and Python build are all using the same compile

Basic questions about Users, Permissions and the "User Mapping Dialog"

[Shaheed Haque]

Hi,

I find myself a bit baffled by User and Permission model. The scenario is:

   - In pgAdmin4, I have a server called "default".
   - Under "default->Databases", I have my application database called
   "foo", with a schema "public".
   - Under "default->Login/Group Roles", I have amongst some other stuff,
   the default user "postgres" and my application-specific user "app_user".
   Naturally, app_user has access to the tables in foo.public.
   - I login to pgAdmin4 as "a...@abc.com".

Normally, when "a...@abc.com" logs in, she is only interested in the
administrative aspects of "foo.public", such as looking at what sessions
are active and so on. That works fine as expected.

In exceptional circumstances, I would like for "a...@abc.com" to be able to
use pgAdmin4 to look at (or even edit) the data in the tables as if she
were app_user. However, when I drill down to
"foo.public->Tables->sometable->View/Edit data", I get a permission denied
error. I guess this makes sense because there is no relationship between
a...@abc.com (a pgAdmin4 user) and app_user (a Postgres user).

I've perused the pgAdmin4 docs and see that there is a section on the "User
Mapping Dialog", but I see no such dialog in the GUI.

Q1. Is that dialog the right place to give a...@abc.com the ability to look
at the data which belongs to app_user?
Q2. If so, how do I make the dialog show up. Or am I barking up the wrong
tree?

Of course I have also poked around the User Management dialog and its docs,
to no avail, so a nudge in the right direction would be appreciated.

Thanks, Shaheed

Re: Basic questions about Users, Permissions and the "User Mapping Dialog"

[Shaheed Haque]

Dave,

On Tue, 26 Mar 2019 at 18:07, Dave Page  wrote:

> Hi
>
> On Tue, Mar 26, 2019 at 1:19 PM Shaheed Haque  wrote:
>
>> Hi,
>>
>> I find myself a bit baffled by User and Permission model. The scenario is:
>>
>>- In pgAdmin4, I have a server called "default".
>>- Under "default->Databases", I have my application database called
>>"foo", with a schema "public".
>>- Under "default->Login/Group Roles", I have amongst some other
>>stuff, the default user "postgres" and my application-specific user
>>"app_user". Naturally, app_user has access to the tables in foo.public.
>>- I login to pgAdmin4 as "a...@abc.com".
>>
>> Normally, when "a...@abc.com" logs in, she is only interested in the
>> administrative aspects of "foo.public", such as looking at what sessions
>> are active and so on. That works fine as expected.
>>
>> In exceptional circumstances, I would like for "a...@abc.com" to be able
>> to use pgAdmin4 to look at (or even edit) the data in the tables as if she
>> were app_user. However, when I drill down to
>> "foo.public->Tables->sometable->View/Edit data", I get a permission denied
>> error. I guess this makes sense because there is no relationship between
>> a...@abc.com (a pgAdmin4 user) and app_user (a Postgres user).
>>
>
> Correct - there is no such relationship. pgAdmin has a completely
> independent set of user accounts to any of the Postgres servers you may use
> it with.
>
> If you're getting permission denied errors, then your Postgres role must
> not have the required permissions for the operation you're trying to
> undertake.
>

Indeed. Or put another way, the pgAdmin Server definition has to connect as
"app_user" and not "postgres". I really ought to have spotted that, but
thanks for the shove anyway.

Shaheed

I've perused the pgAdmin4 docs and see that there is a section on the "User
>> Mapping Dialog", but I see no such dialog in the GUI.
>>
>
> It's there - but it's unrelated to this. User Mapping's are a sub-property
> of Foreign Servers, so you can't even see the dialog unless you have a
> Foreign Server to work with.
>
>
>>
>> Q1. Is that dialog the right place to give a...@abc.com the ability to
>> look at the data which belongs to app_user?
>>
>
> No. You need to look at the permissions in PostgreSQL. You can do that
> with pgAdmin of course - select the table you cannot access, and look at
> the ACL for it to make sure your role has insert/update/delete permissions.
>
>
>> Q2. If so, how do I make the dialog show up. Or am I barking up the wrong
>> tree?
>>
>
> The wrong tree :-)
>
>
>>
>> Of course I have also poked around the User Management dialog and its
>> docs, to no avail, so a nudge in the right direction would be appreciated.
>>
>> Thanks, Shaheed
>>
>>
>>
>>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

Hi Dave,

I'm just migrating to the fixes in 4.4. Can I just double check one
thing? In my original hack, I needed to create a link "wsgi.py" ->
"pgAdmin4.py", so the the corresponding gunicorn command is something
like this:

gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application

Now, in the documentation updates as part of this fix, the last
argument to that line reads "pgAdmin4:app" and not "wsgi:application".
The reason I though I needed to use the wsgi.py file is that it
contains these lines amongst other:

# Ensure the global server mode is set.
builtins.SERVER_MODE = True

I'm not sure if, by following the updated docs, I am missing a
necessary setting?

Thanks, Shaheed

On Tue, 5 Mar 2019 at 09:11, Dave Page  wrote:
>
> You're welcome. Sorry it took so long to realise the main issue was only 
> applicable to Gunicorn!
>
> On Mon, Mar 4, 2019 at 6:29 PM Shaheed Haque  wrote:
>>
>> Dave,
>>
>> Thanks for taking this forward, I look forward to 4.4! I also noted with 
>> interest that we can use "pgAdmin4:app" rather than my hacky link to the 
>> pgAdmin4.wsgi, so that means a completely hack-free solution :-).
>>
>>
>> Shaheed
>>
>> On Mon, 4 Mar 2019 at 16:33, Dave Page  wrote:
>>>
>>> Hi
>>>
>>> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque  wrote:
>>>>
>>>> OK, I got it working. This is how...
>>>>
>>>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque  wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > I'm a relative noob when it comes to the world of nginx, wsgi and so 
>>>> > forth, but I do have several other things working (a Django app under 
>>>> > gunicorn and the RabbitMQ web UI directly behind nginx). However, I'm 
>>>> > rather stuck getting pgAdmin4 to run at http://mydomain.com:80/pgadmin 
>>>> > behind nginx. Is there a simple, up-to-date example of how to do this 
>>>> > (I'm running the latest, v4.2, of pgAdmin4)?
>>>> >
>>>> > I'm aware of threads such as 
>>>> > https://www.postgresql.org/message-id/2197768425D7F5479A0FFB3FEC212F7FF602B871%40aesmail.surcouf.local,
>>>> >  and several others but not been able to come up with a clear approach:
>>>> >
>>>> > One of the several variables I'm struggling to understand is the choice 
>>>> > of whether to run pgAdmin4.py on port 5050 directly behind nginx, or as 
>>>> > a WSGI app under gunicorn. I assume the latter should be easier to set 
>>>> > up, but I've tried both (modelled on what I have working, and various 
>>>> > references). One combination I tried was:
>>>> >
>>>> > - Creating a softlink from pgadmin4.py to pgAdmin4.wsgi
>>>> > - Using gunicorn to run the pgadmin4.py to a unix domain socket like 
>>>> > this:
>>>> >
>>>> > $ /usr/local/bin/gunicorn -w 1 --bind unix:/home/ubuntu/pgadmin.sock 
>>>> > pgadmin4:application
>>>> >
>>>> > - Serving behind nginx like this:
>>>> >
>>>> > location /pgadmin {
>>>> > rewrite ^/pgadmin/(.*) /$1 break;
>>>> > include proxy_params;
>>>> > proxy_pass http://unix:/home/ubuntu/pgadmin.sock;
>>>> > }
>>>> >
>>>> > But all I get is a stubborn 404. Any pointers welcome...
>>>>
>>>> First, I got over the 404s (caused, it seems, by me forgetting just how 
>>>> much my browser had cached :-0). The next problem was with the nginx 
>>>> config fragment: as soon as pgAdmin responded, it of course started the 
>>>> browser looking for top level URLs such as /browser and /static which are 
>>>> obviously not under /pgadmin. The to this key was a piece of code in 
>>>> https://stackoverflow.com/a/50515636/6332554, which basically adds the 
>>>> concept of a SCRIPT_NAME by hacking a small wodge of code into pgAdmin4.py.
>>>>
>>>> The SCRIPT_NAME is set by an nginx fragment like this:
>>>>
>>>> location /pgadmin {
>>>> rewrite ^/pgadmin/(.*)$ /\$1 break;
>>>> include proxy_params;
>>>> proxy_pass http://unix:/home/$CLOUD_USER/pgadmin.sock;
>>>> proxy_set_header X-Script-Name /pgadmin;
>>>> }
>>>>
>>>> In addition to t

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

I can login, but when I click on "Servers", nothing happens on screen
and the error log gets this:

[2019-04-04 16:10:10 +] [5850] [INFO] Starting gunicorn 19.9.0
[2019-04-04 16:10:10 +] [5850] [INFO] Listening at:
unix:/home/ubuntu/pgadmin.sock (5850)
[2019-04-04 16:10:10 +] [5850] [INFO] Using worker: gthread
[2019-04-04 16:10:10 +] [5853] [INFO] Booting worker with pid: 5853
2019-04-04 16:10:25,732: ERROR  flask.app:
'psycopg2.extensions.Column' object has no attribute '_asdict'
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
1813, in full_dispatch_request
rv = self.dispatch_request()
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
1799, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 88, in view
return self.dispatch_request(*args, **kwargs)
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
line 259, in dispatch_request
return method(*args, **kwargs)
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
line 309, in children
children.extend(module.get_nodes(*args, **kwargs))
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
line 127, in get_nodes
in_recovery, wal_paused = recovery_state(conn, manager.version)
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
line 52, in recovery_state
status, result = connection.execute_dict(recovery_check_sql)
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
line 1202, in execute_dict
desc.to_dict() for desc in cur.ordered_description()
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
line 1202, in 
desc.to_dict() for desc in cur.ordered_description()
  File 
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/cursor.py",
line 94, in to_dict
ores = OrderedDict(self.orig_col._asdict())
AttributeError: 'psycopg2.extensions.Column' object has no attribute '_asdict'

It seems as though the version of psycopg2 is not what is expected,
rather than anything to do with "builtins.SERVER_MODE = True"? By way
of full disclosure, I do in fact have both psycopg2 AND
psycopg2-binary installed [1] but some quick experiments removing one
or other did not solve the problem.

Have I overlooked something?

Thanks, Shaheed

[1] this came up in another discussion recently, and it seems that I
ought to remove the psycopg2-binary though 4.2 was OK with this setup.

On Thu, 4 Apr 2019 at 15:04, Dave Page  wrote:
>
> Hi
>
> It worked fine when I tested it. If you don't get any errors and you get a 
> login prompt, it should all be good.
>
> On Thu, Apr 4, 2019 at 3:01 PM Shaheed Haque  wrote:
>>
>> Hi Dave,
>>
>> I'm just migrating to the fixes in 4.4. Can I just double check one
>> thing? In my original hack, I needed to create a link "wsgi.py" ->
>> "pgAdmin4.py", so the the corresponding gunicorn command is something
>> like this:
>>
>> gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
>>
>> Now, in the documentation updates as part of this fix, the last
>> argument to that line reads "pgAdmin4:app" and not "wsgi:application".
>> The reason I though I needed to use the wsgi.py file is that it
>> contains these lines amongst other:
>>
>> # Ensure the global server mode is set.
>> builtins.SERVER_MODE = True
>>
>> I'm not sure if, by following the updated docs, I am missing a
>> necessary setting?
>>
>> Thanks, Shaheed
>>
>> On Tue, 5 Mar 2019 at 09:11, Dave Page  wrote:
>> >
>> > You're welcome. Sorry it took so long to realise the main issue was only 
>> > applicable to Gunicorn!
>> >
>> > On Mon, Mar 4, 2019 at 6:29 PM Shaheed Haque  wrote:
>> >>
>> >> Dave,
>> >>
>> >> Thanks for taking this forward, I look forward to 4.4! I also noted with 
>> >> interest that we can use "pgAdmin4:app" rather than my hacky link to the 
>> >> pgAdmin4.wsgi, so that means a completely hack-free solution :-).
>> >>
>> >>
>> >> Shaheed
>> >>
>> >> On Mon, 4 Mar 2019 at 16:33, Dave Page  wrote:
>> >>>
>> >>> Hi
>> >>>
>> >>> 

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

Woah, rabbithole time...

On Thu, 4 Apr 2019 at 17:33, Shaheed Haque  wrote:
>
> I can login, but when I click on "Servers", nothing happens on screen
> and the error log gets this:
>
> [2019-04-04 16:10:10 +] [5850] [INFO] Starting gunicorn 19.9.0
> [2019-04-04 16:10:10 +] [5850] [INFO] Listening at:
> unix:/home/ubuntu/pgadmin.sock (5850)
> [2019-04-04 16:10:10 +] [5850] [INFO] Using worker: gthread
> [2019-04-04 16:10:10 +] [5853] [INFO] Booting worker with pid: 5853
> 2019-04-04 16:10:25,732: ERROR  flask.app:
> 'psycopg2.extensions.Column' object has no attribute '_asdict'
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> 1813, in full_dispatch_request
> rv = self.dispatch_request()
>   File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> 1799, in dispatch_request
> return self.view_functions[rule.endpoint](**req.view_args)
>   File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 88, in 
> view
> return self.dispatch_request(*args, **kwargs)
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> line 259, in dispatch_request
> return method(*args, **kwargs)
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> line 309, in children
> children.extend(module.get_nodes(*args, **kwargs))
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> line 127, in get_nodes
> in_recovery, wal_paused = recovery_state(conn, manager.version)
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> line 52, in recovery_state
> status, result = connection.execute_dict(recovery_check_sql)
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> line 1202, in execute_dict
> desc.to_dict() for desc in cur.ordered_description()
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> line 1202, in 
> desc.to_dict() for desc in cur.ordered_description()
>   File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/cursor.py",
> line 94, in to_dict
> ores = OrderedDict(self.orig_col._asdict())
> AttributeError: 'psycopg2.extensions.Column' object has no attribute '_asdict'
>
> It seems as though the version of psycopg2 is not what is expected,
> rather than anything to do with "builtins.SERVER_MODE = True"? By way
> of full disclosure, I do in fact have both psycopg2 AND
> psycopg2-binary installed [1] but some quick experiments removing one
> or other did not solve the problem.
>
> Have I overlooked something?

I reverted to 4.2 and started seeing the same error. Then I remembered
that I was prompted to upgrade to 4.4 by *another* issue which was
that from today (as in, this was not happening yesterday) my install
of the 4.2 wheel started failing with complaints about a missing
libpq-dev. I had addressed that by simply "apt install libpq-dev",
implying it is the header files in this library development support
package that are the root of the problem.

I'm unclear what to try next. Maybe get rid of the
psycopg-binary/psycopg duplication will help? At any rate, I am dead
in the water...

Clues appreciated!

Thanks, Shaheed

> Thanks, Shaheed
>
> [1] this came up in another discussion recently, and it seems that I
> ought to remove the psycopg2-binary though 4.2 was OK with this setup.
>
> On Thu, 4 Apr 2019 at 15:04, Dave Page  wrote:
> >
> > Hi
> >
> > It worked fine when I tested it. If you don't get any errors and you get a 
> > login prompt, it should all be good.
> >
> > On Thu, Apr 4, 2019 at 3:01 PM Shaheed Haque  wrote:
> >>
> >> Hi Dave,
> >>
> >> I'm just migrating to the fixes in 4.4. Can I just double check one
> >> thing? In my original hack, I needed to create a link "wsgi.py" ->
> >> "pgAdmin4.py", so the the corresponding gunicorn command is something
> >> like this:
> >>
> >> gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
> >>
> >> Now, in the documentation updates as part of this fix, the last
> >> argument to that line reads "pgAdmin4:app" and not "wsgi:application".
> >> The reason I though I needed to use the wsgi.py file is that it
> >> contains t

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

On Thu, 4 Apr 2019 at 17:57, Shaheed Haque  wrote:
>
> Woah, rabbithole time...
>
> On Thu, 4 Apr 2019 at 17:33, Shaheed Haque  wrote:
> >
> > I can login, but when I click on "Servers", nothing happens on screen
> > and the error log gets this:
> >
> > [2019-04-04 16:10:10 +] [5850] [INFO] Starting gunicorn 19.9.0
> > [2019-04-04 16:10:10 +] [5850] [INFO] Listening at:
> > unix:/home/ubuntu/pgadmin.sock (5850)
> > [2019-04-04 16:10:10 +] [5850] [INFO] Using worker: gthread
> > [2019-04-04 16:10:10 +] [5853] [INFO] Booting worker with pid: 5853
> > 2019-04-04 16:10:25,732: ERROR  flask.app:
> > 'psycopg2.extensions.Column' object has no attribute '_asdict'
> > Traceback (most recent call last):
> >   File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> > 1813, in full_dispatch_request
> > rv = self.dispatch_request()
> >   File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> > 1799, in dispatch_request
> > return self.view_functions[rule.endpoint](**req.view_args)
> >   File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 88, in 
> > view
> > return self.dispatch_request(*args, **kwargs)
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> > line 259, in dispatch_request
> > return method(*args, **kwargs)
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> > line 309, in children
> > children.extend(module.get_nodes(*args, **kwargs))
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> > line 127, in get_nodes
> > in_recovery, wal_paused = recovery_state(conn, manager.version)
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> > line 52, in recovery_state
> > status, result = connection.execute_dict(recovery_check_sql)
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> > line 1202, in execute_dict
> > desc.to_dict() for desc in cur.ordered_description()
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> > line 1202, in 
> > desc.to_dict() for desc in cur.ordered_description()
> >   File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/cursor.py",
> > line 94, in to_dict
> > ores = OrderedDict(self.orig_col._asdict())
> > AttributeError: 'psycopg2.extensions.Column' object has no attribute 
> > '_asdict'
> >
> > It seems as though the version of psycopg2 is not what is expected,
> > rather than anything to do with "builtins.SERVER_MODE = True"? By way
> > of full disclosure, I do in fact have both psycopg2 AND
> > psycopg2-binary installed [1] but some quick experiments removing one
> > or other did not solve the problem.
> >
> > Have I overlooked something?
>
> I reverted to 4.2 and started seeing the same error. Then I remembered
> that I was prompted to upgrade to 4.4 by *another* issue which was
> that from today (as in, this was not happening yesterday) my install
> of the 4.2 wheel started failing with complaints about a missing
> libpq-dev. I had addressed that by simply "apt install libpq-dev",
> implying it is the header files in this library development support
> package that are the root of the problem.

I was nearly right. The actual root cause seems to be that psycopg2
released 2.8 today, and that appears to be incompatible with pgAdmin
4.2 and 4.4. For now, I'll try a downgrade to psycopg2 2.7.7 (and get
rid of the psycopg2-binary while I am at it).

Hope that helps,

Thanks, Shaheed

> I'm unclear what to try next. Maybe get rid of the
> psycopg-binary/psycopg duplication will help? At any rate, I am dead
> in the water...
>
> Clues appreciated!
>
> Thanks, Shaheed
>
> > Thanks, Shaheed
> >
> > [1] this came up in another discussion recently, and it seems that I
> > ought to remove the psycopg2-binary though 4.2 was OK with this setup.
> >
> > On Thu, 4 Apr 2019 at 15:04, Dave Page  wrote:
> > >
> > > Hi
> > >
> > > It worked fine when I tested it. If you don't get any errors and you get 
> > > a login prompt, it should all be good.
> > &g

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

Thanks for the kind (and quick) replies. My last email crossed with
the ones from Dave and Murtaza...

On Thu, 4 Apr 2019 at 19:03, Dave Page  wrote:
>
> Downgrade psycopg2 to 2.7.7 (or whatever came before 2.8). Apparently they 
> broke backwards compatibility:-(
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK:http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> On 4 Apr 2019, at 17:33, Shaheed Haque  wrote:
>
> I can login, but when I click on "Servers", nothing happens on screen
> and the error log gets this:
>
> [2019-04-04 16:10:10 +] [5850] [INFO] Starting gunicorn 19.9.0
> [2019-04-04 16:10:10 +] [5850] [INFO] Listening at:
> unix:/home/ubuntu/pgadmin.sock (5850)
> [2019-04-04 16:10:10 +] [5850] [INFO] Using worker: gthread
> [2019-04-04 16:10:10 +] [5853] [INFO] Booting worker with pid: 5853
> 2019-04-04 16:10:25,732: ERROR  flask.app:
> 'psycopg2.extensions.Column' object has no attribute '_asdict'
> Traceback (most recent call last):
>  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> 1813, in full_dispatch_request
>rv = self.dispatch_request()
>  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> 1799, in dispatch_request
>return self.view_functions[rule.endpoint](**req.view_args)
>  File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 88, in 
> view
>return self.dispatch_request(*args, **kwargs)
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> line 259, in dispatch_request
>return method(*args, **kwargs)
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> line 309, in children
>children.extend(module.get_nodes(*args, **kwargs))
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> line 127, in get_nodes
>in_recovery, wal_paused = recovery_state(conn, manager.version)
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> line 52, in recovery_state
>status, result = connection.execute_dict(recovery_check_sql)
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> line 1202, in execute_dict
>desc.to_dict() for desc in cur.ordered_description()
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> line 1202, in 
>desc.to_dict() for desc in cur.ordered_description()
>  File 
> "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/cursor.py",
> line 94, in to_dict
>ores = OrderedDict(self.orig_col._asdict())
> AttributeError: 'psycopg2.extensions.Column' object has no attribute '_asdict'
>
> It seems as though the version of psycopg2 is not what is expected,
> rather than anything to do with "builtins.SERVER_MODE = True"? By way
> of full disclosure, I do in fact have both psycopg2 AND
> psycopg2-binary installed [1] but some quick experiments removing one
> or other did not solve the problem.
>
> Have I overlooked something?
>
> Thanks, Shaheed
>
> [1] this came up in another discussion recently, and it seems that I
> ought to remove the psycopg2-binary though 4.2 was OK with this setup.
>
> On Thu, 4 Apr 2019 at 15:04, Dave Page  wrote:
>
>
> Hi
>
>
> It worked fine when I tested it. If you don't get any errors and you get a 
> login prompt, it should all be good.
>
>
> On Thu, Apr 4, 2019 at 3:01 PM Shaheed Haque  wrote:
>
>
> Hi Dave,
>
>
> I'm just migrating to the fixes in 4.4. Can I just double check one
>
> thing? In my original hack, I needed to create a link "wsgi.py" ->
>
> "pgAdmin4.py", so the the corresponding gunicorn command is something
>
> like this:
>
>
>gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
>
>
> Now, in the documentation updates as part of this fix, the last
>
> argument to that line reads "pgAdmin4:app" and not "wsgi:application".
>
> The reason I though I needed to use the wsgi.py file is that it
>
> contains these lines amongst other:
>
>
># Ensure the global server mode is set.
>
>builtins.SERVER_MODE = True
>
>
> I'm not sure if, by following the updated docs, I am missing a
>
> necessary setting?
>
>
> Thanks, Shaheed
>
>
> On Tue, 5 Mar 2019 at 09:11, Dave Page

Re: Hosting pgAdmin4 behind nginx and at /pgdmin, for mortals

[Shaheed Haque]

This issue is tracked here: https://redmine.postgresql.org/issues/4143.

On Thu, 4 Apr 2019 at 19:06, Shaheed Haque  wrote:
>
> Thanks for the kind (and quick) replies. My last email crossed with
> the ones from Dave and Murtaza...
>
> On Thu, 4 Apr 2019 at 19:03, Dave Page  wrote:
> >
> > Downgrade psycopg2 to 2.7.7 (or whatever came before 2.8). Apparently they 
> > broke backwards compatibility:-(
> >
> > --
> > Dave Page
> > Blog: http://pgsnake.blogspot.com
> > Twitter: @pgsnake
> >
> > EnterpriseDB UK:http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
> >
> > On 4 Apr 2019, at 17:33, Shaheed Haque  wrote:
> >
> > I can login, but when I click on "Servers", nothing happens on screen
> > and the error log gets this:
> >
> > [2019-04-04 16:10:10 +] [5850] [INFO] Starting gunicorn 19.9.0
> > [2019-04-04 16:10:10 +] [5850] [INFO] Listening at:
> > unix:/home/ubuntu/pgadmin.sock (5850)
> > [2019-04-04 16:10:10 +] [5850] [INFO] Using worker: gthread
> > [2019-04-04 16:10:10 +] [5853] [INFO] Booting worker with pid: 5853
> > 2019-04-04 16:10:25,732: ERROR  flask.app:
> > 'psycopg2.extensions.Column' object has no attribute '_asdict'
> > Traceback (most recent call last):
> >  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> > 1813, in full_dispatch_request
> >rv = self.dispatch_request()
> >  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
> > 1799, in dispatch_request
> >return self.view_functions[rule.endpoint](**req.view_args)
> >  File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 88, in 
> > view
> >return self.dispatch_request(*args, **kwargs)
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> > line 259, in dispatch_request
> >return method(*args, **kwargs)
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
> > line 309, in children
> >children.extend(module.get_nodes(*args, **kwargs))
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> > line 127, in get_nodes
> >in_recovery, wal_paused = recovery_state(conn, manager.version)
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
> > line 52, in recovery_state
> >status, result = connection.execute_dict(recovery_check_sql)
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> > line 1202, in execute_dict
> >desc.to_dict() for desc in cur.ordered_description()
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
> > line 1202, in 
> >desc.to_dict() for desc in cur.ordered_description()
> >  File 
> > "/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/cursor.py",
> > line 94, in to_dict
> >ores = OrderedDict(self.orig_col._asdict())
> > AttributeError: 'psycopg2.extensions.Column' object has no attribute 
> > '_asdict'
> >
> > It seems as though the version of psycopg2 is not what is expected,
> > rather than anything to do with "builtins.SERVER_MODE = True"? By way
> > of full disclosure, I do in fact have both psycopg2 AND
> > psycopg2-binary installed [1] but some quick experiments removing one
> > or other did not solve the problem.
> >
> > Have I overlooked something?
> >
> > Thanks, Shaheed
> >
> > [1] this came up in another discussion recently, and it seems that I
> > ought to remove the psycopg2-binary though 4.2 was OK with this setup.
> >
> > On Thu, 4 Apr 2019 at 15:04, Dave Page  wrote:
> >
> >
> > Hi
> >
> >
> > It worked fine when I tested it. If you don't get any errors and you get a 
> > login prompt, it should all be good.
> >
> >
> > On Thu, Apr 4, 2019 at 3:01 PM Shaheed Haque  wrote:
> >
> >
> > Hi Dave,
> >
> >
> > I'm just migrating to the fixes in 4.4. Can I just double check one
> >
> > thing? In my original hack, I needed to create a link "wsgi.py" ->
> >
> > "pgAdmin4.py", so the the corresponding gunicorn command is something
> >
> > like this:
> >

Re: Noisy dependency on psycopg2 versus psycopg2-binary

[Shaheed Haque]

Wow, I have just seen that 4.6 implements
https://redmine.postgresql.org/issues/4165: excellent!

On Wed, 20 Mar 2019 at 13:35, Shaheed Haque  wrote:

> Dave, Khushboo,
>
> Just to be clear, I'm expecting to install multiple packages which depend
> on Python access to PostgreSQL, of which pgAdmin is one. So I would ask
> that any solution be clear as to what an end user needs to do to ensure the
> various packages can co-exist. I'm more or less happy to assume that the
> versions won't drift uncontrollably, but if two different builds of the
> same version are needed then any proposed solution needs to address that
> please.
>
> I hope that sounds sane.
>
> Thanks, Shaheed
>
> On Wed, 20 Mar 2019 at 12:32, Dave Page  wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 12:21 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 20, 2019 at 5:49 PM Dave Page  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 12:11 PM Khushboo Vashi <
>>>> khushboo.va...@enterprisedb.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 20, 2019 at 4:54 PM Dave Page  wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Wed, Mar 20, 2019 at 9:50 AM Shaheed Haque 
>>>>>> wrote:
>>>>>>
>>>>>>> My goodness...
>>>>>>>
>>>>>>
>>>>>> Indeed.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, 20 Mar 2019 at 09:18, Dave Page  wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Wed, Mar 20, 2019 at 6:18 AM Khushboo Vashi <
>>>>>>>> khushboo.va...@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 19, 2019 at 10:24 PM Dave Page 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 19, 2019 at 1:37 PM Shaheed Haque 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, 19 Mar 2019 at 10:28, Dave Page 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 19, 2019 at 10:19 AM Shaheed Haque <
>>>>>>>>>>>> srha...@theiet.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm still on 4.2, but checking the release notes for 4.3
>>>>>>>>>>>>> suggests it too has the problem of being dependent on psycopg2 
>>>>>>>>>>>>> versus
>>>>>>>>>>>>> psycopg2-binary. This results in the annoying message:
>>>>>>>>>>>>>
>>>>>>>>>>>>> /usr/local/lib/python3.6/dist-packages/psycopg2/__init__.py:144:
>>>>>>>>>>>>>> UserWarning: The psycopg2 wheel package will be renamed from 
>>>>>>>>>>>>>> release 2.8;
>>>>>>>>>>>>>> in order to keep installing from binary please use "pip install
>>>>>>>>>>>>>> psycopg2-binary" instead. For details see: <
>>>>>>>>>>>>>> http://initd.org/psycopg/docs/install.html#binary-install-from-pypi
>>>>>>>>>>>>>> >.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> My package also had this problem, and the fix was to replace
>>>>>>>>>>>>> the reference to psycopg2 with  psycopg2-binary in setup.py. I 
>>>>>>>>>>>>> hope that
>>>>>>>>>>>>> helps,
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>&g

Any plans for a PyPi release?

[Shaheed Haque]

Hi,

I've had a quick look, and while I see the odd reference to PyPi in the
archives, I'm not sure if there has ever been discussion of having a PyPi
release for pgAdmin.

I am of course aware of the packaging changes w.r.t. psycopg2 and
psycopg2-binary in 4.6, but did wonder if that might open the door in that
regard?

This is of interest to me because when we deploy, we cannot avoid a
dependency of PyPi for lots of stuff. But right now, in addition to that,
we also manually maintain a dependency on a handful of packages such as
pgAdmin. This in variably means we fall behind on these, and on balance,
the minimal extra exposure to Pypi wuld be much preferable. I suspect that
there are others in a similar position.

So, any thoughts on making pgAdmin4 available on PyPi??

Thanks, Shaheed

Re: Any plans for a PyPi release?

[Shaheed Haque]

Cool, thanks! I'll keep an eye out for it...

On Thu, 8 Aug 2019 at 12:40, Dave Page  wrote:

> Hi
>
> On Thu, Aug 8, 2019 at 12:31 PM Shaheed Haque 
> wrote:
>
>> Hi,
>>
>> I've had a quick look, and while I see the odd reference to PyPi in the
>> archives, I'm not sure if there has ever been discussion of having a PyPi
>> release for pgAdmin.
>>
>> I am of course aware of the packaging changes w.r.t. psycopg2 and
>> psycopg2-binary in 4.6, but did wonder if that might open the door in that
>> regard?
>>
>> This is of interest to me because when we deploy, we cannot avoid a
>> dependency of PyPi for lots of stuff. But right now, in addition to that,
>> we also manually maintain a dependency on a handful of packages such as
>> pgAdmin. This in variably means we fall behind on these, and on balance,
>> the minimal extra exposure to Pypi wuld be much preferable. I suspect that
>> there are others in a similar position.
>>
>> So, any thoughts on making pgAdmin4 available on PyPi??
>>
>
> Yes, but I just never got round to figuring out all the details. It's on
> my personal TODO list.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Any plans for a PyPi release?

[Shaheed Haque]

Is this tracked anywhere, or should I file a request?

On Thu, 8 Aug 2019, 15:03 Shaheed Haque,  wrote:

> Cool, thanks! I'll keep an eye out for it...
>
> On Thu, 8 Aug 2019 at 12:40, Dave Page  wrote:
>
>> Hi
>>
>> On Thu, Aug 8, 2019 at 12:31 PM Shaheed Haque 
>> wrote:
>>
>>> Hi,
>>>
>>> I've had a quick look, and while I see the odd reference to PyPi in the
>>> archives, I'm not sure if there has ever been discussion of having a PyPi
>>> release for pgAdmin.
>>>
>>> I am of course aware of the packaging changes w.r.t. psycopg2 and
>>> psycopg2-binary in 4.6, but did wonder if that might open the door in that
>>> regard?
>>>
>>> This is of interest to me because when we deploy, we cannot avoid a
>>> dependency of PyPi for lots of stuff. But right now, in addition to that,
>>> we also manually maintain a dependency on a handful of packages such as
>>> pgAdmin. This in variably means we fall behind on these, and on balance,
>>> the minimal extra exposure to Pypi wuld be much preferable. I suspect that
>>> there are others in a similar position.
>>>
>>> So, any thoughts on making pgAdmin4 available on PyPi??
>>>
>>
>> Yes, but I just never got round to figuring out all the details. It's on
>> my personal TODO list.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>

Dashboard graphs are not drawn with 4.20 or 4.21

[Shaheed Haque]

Hi,

I have been running 4.14 for a while, and today in order to get to a newer
version of werkzeug, I tried upgrading to 4.21 only to find that the
Dashboard graphs are not being drawn. All else seems fine (I can navigate
down to tables, and view data for example), but none of the graphs a re
drawn.

I notice that on the console from where I am running pgAdmin 4.21, I see
messages like this every few seconds:

SQL:flask.app:Execute (dict) for server #1 - DB:foo (Query-id: 8996147):
/*pga4dash*/
SELECT 'session_stats' AS chart_name, row_to_json(t) AS chart_data
FROM (SELECT
   (SELECT count(*) FROM pg_stat_activity WHERE datname = (SELECT datname
FROM pg_database WHERE oid = 1680798)) AS "Total",
   (SELECT count(*) FROM pg_stat_activity WHERE state = 'active' AND
datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS
"Active",
   (SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND datname
= (SELECT datname FROM pg_database WHERE oid = 1680798))  AS "Idle"
) t
UNION ALL
...
more like this
...

which suggests something is trying to fetch the needed data. I tried
restarting the browser, to no avail.

I did also notice:

- A dependency on pyasn1.error which I resolved by updating from
pyasn1-0.4.5 to pyasn1-0.4.8:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgAdmin4.py", line
109, in 
app = create_app()
  File
"/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/__init__.py", line
401, in create_app
authenticate.init_app(app)
  File
"/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/__init__.py",
line 154, in init_app
AuthSourceRegistry.load_auth_sources()
  File
"/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/registry.py",
line 65, in load_auth_sources
module = import_module(module_name)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1006, in _gcd_import
  File "", line 983, in _find_and_load
  File "", line 967, in _find_and_load_unlocked
  File "", line 677, in _load_unlocked
  File "", line 728, in exec_module
  File "", line 219, in
_call_with_frames_removed
  File
"/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/ldap.py",
line 14, in 
from ldap3 import Connection, Server, Tls, ALL, ALL_ATTRIBUTES
  File "/usr/local/lib/python3.7/dist-packages/ldap3/__init__.py", line
139, in 
from .core.connection import Connection
  File "/usr/local/lib/python3.7/dist-packages/ldap3/core/connection.py",
line 44, in 
from ..operation.compare import compare_operation,
compare_request_to_dict
  File "/usr/local/lib/python3.7/dist-packages/ldap3/operation/compare.py",
line 28, in 
from ..operation.search import ava_to_dict
  File "/usr/local/lib/python3.7/dist-packages/ldap3/operation/search.py",
line 41, in 
from pyasn1.error import PyAsn1UnicodeDecodeError
ImportError: cannot import name 'PyAsn1UnicodeDecodeError' from
'pyasn1.error' (/usr/local/lib/python3.7/dist-packages/pyasn1/error.py)

- A compatibility problem with werkzeug. I had been running 0.15.2, and
tried upgrading to 1.0.1 to address some long standing issues (I believe
you guys were also hit by changes in legacy API support too) only to get
this:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgAdmin4.py", line
40, in 
import config
  File "/usr/local/lib/python3.7/dist-packages/pgadmin4/config.py", line
30, in 
from pgadmin.utils import env, IS_PY2, IS_WIN, fs_short_path
  File
"/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/__init__.py", line
21, in 
from flask_babelex import Babel, gettext
  File "/usr/local/lib/python3.7/dist-packages/flask_babelex/__init__.py",
line 23, in 
from werkzeug import ImmutableDict
ImportError: cannot import name 'ImmutableDict' from 'werkzeug'
(/usr/local/lib/python3.7/dist-packages/werkzeug/__init__.py)

I downgraded to werkzeug 0.16.1 to address this.

The results I noted were AFTER these fixes were applied. FWIW, I am running
on a recent Ubuntu desktop.

Any advice welcome.

Thanks, Shaheed

Re: Dashboard graphs are not drawn with 4.20 or 4.21

[Shaheed Haque]

I forgot to add: I also tried 4.20 in case it was any better, but it had
the same lack of graph drawing, so went back to 4.21 pending advice.

On Thu, 30 Apr 2020 at 15:43, Shaheed Haque  wrote:

> Hi,
>
> I have been running 4.14 for a while, and today in order to get to a newer
> version of werkzeug, I tried upgrading to 4.21 only to find that the
> Dashboard graphs are not being drawn. All else seems fine (I can navigate
> down to tables, and view data for example), but none of the graphs a re
> drawn.
>
> I notice that on the console from where I am running pgAdmin 4.21, I see
> messages like this every few seconds:
>
> SQL:flask.app:Execute (dict) for server #1 - DB:foo (Query-id: 8996147):
> /*pga4dash*/
> SELECT 'session_stats' AS chart_name, row_to_json(t) AS chart_data
> FROM (SELECT
>(SELECT count(*) FROM pg_stat_activity WHERE datname = (SELECT datname
> FROM pg_database WHERE oid = 1680798)) AS "Total",
>(SELECT count(*) FROM pg_stat_activity WHERE state = 'active' AND
> datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS
> "Active",
>(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND datname
> = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS "Idle"
> ) t
> UNION ALL
> ...
> more like this
> ...
>
> which suggests something is trying to fetch the needed data. I tried
> restarting the browser, to no avail.
>
> I did also notice:
>
> - A dependency on pyasn1.error which I resolved by updating from
> pyasn1-0.4.5 to pyasn1-0.4.8:
>
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgAdmin4.py", line
> 109, in 
> app = create_app()
>   File
> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/__init__.py", line
> 401, in create_app
> authenticate.init_app(app)
>   File
> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/__init__.py",
> line 154, in init_app
> AuthSourceRegistry.load_auth_sources()
>   File
> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/registry.py",
> line 65, in load_auth_sources
> module = import_module(module_name)
>   File "/usr/lib/python3.7/importlib/__init__.py", line 127, in
> import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1006, in _gcd_import
>   File "", line 983, in _find_and_load
>   File "", line 967, in
> _find_and_load_unlocked
>   File "", line 677, in _load_unlocked
>   File "", line 728, in exec_module
>   File "", line 219, in
> _call_with_frames_removed
>   File
> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/ldap.py",
> line 14, in 
> from ldap3 import Connection, Server, Tls, ALL, ALL_ATTRIBUTES
>   File "/usr/local/lib/python3.7/dist-packages/ldap3/__init__.py", line
> 139, in 
> from .core.connection import Connection
>   File "/usr/local/lib/python3.7/dist-packages/ldap3/core/connection.py",
> line 44, in 
> from ..operation.compare import compare_operation,
> compare_request_to_dict
>   File
> "/usr/local/lib/python3.7/dist-packages/ldap3/operation/compare.py", line
> 28, in 
> from ..operation.search import ava_to_dict
>   File "/usr/local/lib/python3.7/dist-packages/ldap3/operation/search.py",
> line 41, in 
> from pyasn1.error import PyAsn1UnicodeDecodeError
> ImportError: cannot import name 'PyAsn1UnicodeDecodeError' from
> 'pyasn1.error' (/usr/local/lib/python3.7/dist-packages/pyasn1/error.py)
>
> - A compatibility problem with werkzeug. I had been running 0.15.2, and
> tried upgrading to 1.0.1 to address some long standing issues (I believe
> you guys were also hit by changes in legacy API support too) only to get
> this:
>
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgAdmin4.py", line
> 40, in 
> import config
>   File "/usr/local/lib/python3.7/dist-packages/pgadmin4/config.py", line
> 30, in 
> from pgadmin.utils import env, IS_PY2, IS_WIN, fs_short_path
>   File
> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/__init__.py", line
> 21, in 
> from flask_babelex import Babel, gettext
>   File "/usr/local/lib/python3.7/dist-packages/flask_babelex/__init__.py",
> line 23, in 
> from werkzeug import ImmutableDict
> ImportError: cannot import name 'ImmutableDict' from 'werkzeug'
> (/usr/local/lib/python3.7/dist-packages/werkzeug/__init__.py)
>
> I downgraded to werkzeug 0.16.1 to address this.
>
> The results I noted were AFTER these fixes were applied. FWIW, I am
> running on a recent Ubuntu desktop.
>
> Any advice welcome.
>
> Thanks, Shaheed
>
>
>

Re: Dashboard graphs are not drawn with 4.20 or 4.21

[Shaheed Haque]

I resolved the wrkzeug issue by updating Flask-BabelEx, but the graphs are
still not drawn.

Also, after restarting pgadmin, the SQL messages are no longer emitted.

On Thu, 30 Apr 2020 at 15:44, Shaheed Haque  wrote:

> I forgot to add: I also tried 4.20 in case it was any better, but it had
> the same lack of graph drawing, so went back to 4.21 pending advice.
>
> On Thu, 30 Apr 2020 at 15:43, Shaheed Haque 
> wrote:
>
>> Hi,
>>
>> I have been running 4.14 for a while, and today in order to get to a
>> newer version of werkzeug, I tried upgrading to 4.21 only to find that the
>> Dashboard graphs are not being drawn. All else seems fine (I can navigate
>> down to tables, and view data for example), but none of the graphs a re
>> drawn.
>>
>> I notice that on the console from where I am running pgAdmin 4.21, I see
>> messages like this every few seconds:
>>
>> SQL:flask.app:Execute (dict) for server #1 - DB:foo (Query-id: 8996147):
>> /*pga4dash*/
>> SELECT 'session_stats' AS chart_name, row_to_json(t) AS chart_data
>> FROM (SELECT
>>(SELECT count(*) FROM pg_stat_activity WHERE datname = (SELECT datname
>> FROM pg_database WHERE oid = 1680798)) AS "Total",
>>(SELECT count(*) FROM pg_stat_activity WHERE state = 'active' AND
>> datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS
>> "Active",
>>(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND
>> datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS "Idle"
>> ) t
>> UNION ALL
>> ...
>> more like this
>> ...
>>
>> which suggests something is trying to fetch the needed data. I tried
>> restarting the browser, to no avail.
>>
>> I did also notice:
>>
>> - A dependency on pyasn1.error which I resolved by updating from
>> pyasn1-0.4.5 to pyasn1-0.4.8:
>>
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgAdmin4.py",
>> line 109, in 
>> app = create_app()
>>   File
>> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/__init__.py", line
>> 401, in create_app
>> authenticate.init_app(app)
>>   File
>> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/__init__.py",
>> line 154, in init_app
>> AuthSourceRegistry.load_auth_sources()
>>   File
>> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/registry.py",
>> line 65, in load_auth_sources
>> module = import_module(module_name)
>>   File "/usr/lib/python3.7/importlib/__init__.py", line 127, in
>> import_module
>> return _bootstrap._gcd_import(name[level:], package, level)
>>   File "", line 1006, in _gcd_import
>>   File "", line 983, in _find_and_load
>>   File "", line 967, in
>> _find_and_load_unlocked
>>   File "", line 677, in _load_unlocked
>>   File "", line 728, in exec_module
>>   File "", line 219, in
>> _call_with_frames_removed
>>   File
>> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/authenticate/ldap.py",
>> line 14, in 
>> from ldap3 import Connection, Server, Tls, ALL, ALL_ATTRIBUTES
>>   File "/usr/local/lib/python3.7/dist-packages/ldap3/__init__.py", line
>> 139, in 
>> from .core.connection import Connection
>>   File "/usr/local/lib/python3.7/dist-packages/ldap3/core/connection.py",
>> line 44, in 
>> from ..operation.compare import compare_operation,
>> compare_request_to_dict
>>   File
>> "/usr/local/lib/python3.7/dist-packages/ldap3/operation/compare.py", line
>> 28, in 
>> from ..operation.search import ava_to_dict
>>   File
>> "/usr/local/lib/python3.7/dist-packages/ldap3/operation/search.py", line
>> 41, in 
>> from pyasn1.error import PyAsn1UnicodeDecodeError
>> ImportError: cannot import name 'PyAsn1UnicodeDecodeError' from
>> 'pyasn1.error' (/usr/local/lib/python3.7/dist-packages/pyasn1/error.py)
>>
>> - A compatibility problem with werkzeug. I had been running 0.15.2, and
>> tried upgrading to 1.0.1 to address some long standing issues (I believe
>> you guys were also hit by changes in legacy API support too) only to get
>> this:
>>
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgAdmin4.py",
>> line 40, in 
>> import config
>>   File "/usr/local/lib/python3.7/dist-packages/pgadmin4/config.py", line
>> 30, in 
>> from pgadmin.utils import env, IS_PY2, IS_WIN, fs_short_path
>>   File
>> "/usr/local/lib/python3.7/dist-packages/pgadmin4/pgadmin/__init__.py", line
>> 21, in 
>> from flask_babelex import Babel, gettext
>>   File
>> "/usr/local/lib/python3.7/dist-packages/flask_babelex/__init__.py", line
>> 23, in 
>> from werkzeug import ImmutableDict
>> ImportError: cannot import name 'ImmutableDict' from 'werkzeug'
>> (/usr/local/lib/python3.7/dist-packages/werkzeug/__init__.py)
>>
>> I downgraded to werkzeug 0.16.1 to address this.
>>
>> The results I noted were AFTER these fixes were applied. FWIW, I am
>> running on a recent Ubuntu desktop.
>>
>> Any advice welcome.
>>
>> Thanks, Shaheed
>>
>>
>>

Re: Dashboard graphs are not drawn with 4.20 or 4.21

[Shaheed Haque]

Good news: I verified that it works fine under Chromium. However, under
Firefox, despite clearing of the cache for localhost, the console has this
error:

ChunkLoadError: Loading chunk 14 failed. (missing:
http://localhost:5050/static/js/generated/vendors~chart.chunk.js) 5
app.bundle.js:1:1137
<http://localhost:5050/static/js/generated/app.bundle.js?ver=42100>

Any thoughts?

Thanks, Shaheed


On Mon, 4 May 2020 at 06:38, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hello,
>
> Not able to find any helpful information in the logs,
>
> 1) Try executing below sql (which is from the pgadmin4 log) in the Query
> tool manually and check if you are getting proper result,
> /*pga4dash*/
> SELECT 'session_stats' AS chart_name, row_to_json(t) AS chart_data
> FROM (SELECT
>(SELECT count(*) FROM pg_stat_activity WHERE datname = (SELECT datname
> FROM pg_database WHERE oid = 1680798)) AS "Total",
>(SELECT count(*) FROM pg_stat_activity WHERE state = 'active' AND
> datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS
> "Active",
>(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND datname
> = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS "Idle"
> ) t
> UNION ALL
> SELECT 'tps_stats' AS chart_name, row_to_json(t) AS chart_data
> FROM (SELECT
>(SELECT sum(xact_commit) + sum(xact_rollback) FROM pg_stat_database
> WHERE datname = (SELECT datname FROM pg_database WHERE oid = 1680798)) AS
> "Transactions",
>(SELECT sum(xact_commit) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Commits",
>(SELECT sum(xact_rollback) FROM pg_stat_database WHERE datname =
> (SELECT datname FROM pg_database WHERE oid = 1680798)) AS "Rollbacks"
> ) t
> UNION ALL
> SELECT 'ti_stats' AS chart_name, row_to_json(t) AS chart_data
> FROM (SELECT
>(SELECT sum(tup_inserted) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Inserts",
>(SELECT sum(tup_updated) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Updates",
>(SELECT sum(tup_deleted) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Deletes"
> ) t
> UNION ALL
> SELECT 'to_stats' AS chart_name, row_to_json(t) AS chart_data
> FROM (SELECT
>(SELECT sum(tup_fetched) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Fetched",
>(SELECT sum(tup_returned) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Returned"
> ) t
> UNION ALL
> SELECT 'bio_stats' AS chart_name, row_to_json(t) AS chart_data
> FROM (SELECT
>(SELECT sum(blks_read) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Reads",
>(SELECT sum(blks_hit) FROM pg_stat_database WHERE datname = (SELECT
> datname FROM pg_database WHERE oid = 1680798)) AS "Hits"
> ) t
>
> 2) Can you hard refresh the browser (remove all browser cache & try again)
> & check for any browser console errors next time when you try to access the
> dashboard?
> 3) Can you cross verify in any other browser if the same issue exists?
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
> On Sun, May 3, 2020 at 1:33 AM Shaheed Haque 
> wrote:
>
>> Here is the information requested...
>>
>> On Fri, 1 May 2020 at 01:10, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Hello,
>>>
>>> Could you please provide additional information like,
>>> What is your platform?
>>>
>>
>> Ubuntu 19.10 on x86-64.
>>
>>
>>> How did you install/upgrade pgAdmin4?
>>>
>>
>> Using the downloaded .whl file, I did a "sudo -H pip3 install --upgrade
>> xxx.whl".
>>
>>
>>> What's the DB server version on which graphs are not displaying?
>>>
>>
>> Postgresql 11, running on another Ubuntu machine.
>>
>>
>>> What browser/version are you using?
>>>
>>
>> Primarily Firefox 75. I have access to Chromium too if needed (I need to
>> figure out how to reet my pgAdmin password...).
>>
>>
>>> Also provide pgAdmin4 logs (Ref:  https://www.pgadmin.org/faq/ on how
>>> to enab

Re: Dashboard graphs are not drawn with 4.20 or 4.21

[Shaheed Haque]

I found the issue. When I looked at the Network traffic in the developer
console, the vendors~chart.chunk.js was still showing as being fetched from
cache. So, I disabled the che using the radio button there, and now the
graphs show up as expected.

Thanks for all your help, and please consider this issue closed.
<http://localhost:5050/static/js/generated/app.bundle.js?ver=42100>
<http://localhost:5050/static/js/generated/app.bundle.js?ver=42100>

On Mon, 4 May 2020 at 11:36, Shaheed Haque  wrote:

>
> Good news: I verified that it works fine under Chromium. However, under
> Firefox, despite clearing of the cache for localhost, the console has this
> error:
>
> ChunkLoadError: Loading chunk 14 failed. (missing:
> http://localhost:5050/static/js/generated/vendors~chart.chunk.js) 5
> app.bundle.js:1:1137
> <http://localhost:5050/static/js/generated/app.bundle.js?ver=42100>
>
> Any thoughts?
>
> Thanks, Shaheed
>
>
> On Mon, 4 May 2020 at 06:38, Murtuza Zabuawala <
> murtuza.zabuaw...@enterprisedb.com> wrote:
>
>> Hello,
>>
>> Not able to find any helpful information in the logs,
>>
>> 1) Try executing below sql (which is from the pgadmin4 log) in the Query
>> tool manually and check if you are getting proper result,
>> /*pga4dash*/
>> SELECT 'session_stats' AS chart_name, row_to_json(t) AS chart_data
>> FROM (SELECT
>>(SELECT count(*) FROM pg_stat_activity WHERE datname = (SELECT datname
>> FROM pg_database WHERE oid = 1680798)) AS "Total",
>>(SELECT count(*) FROM pg_stat_activity WHERE state = 'active' AND
>> datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS
>> "Active",
>>(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND
>> datname = (SELECT datname FROM pg_database WHERE oid = 1680798))  AS "Idle"
>> ) t
>> UNION ALL
>> SELECT 'tps_stats' AS chart_name, row_to_json(t) AS chart_data
>> FROM (SELECT
>>(SELECT sum(xact_commit) + sum(xact_rollback) FROM pg_stat_database
>> WHERE datname = (SELECT datname FROM pg_database WHERE oid = 1680798)) AS
>> "Transactions",
>>(SELECT sum(xact_commit) FROM pg_stat_database WHERE datname = (SELECT
>> datname FROM pg_database WHERE oid = 1680798)) AS "Commits",
>>(SELECT sum(xact_rollback) FROM pg_stat_database WHERE datname =
>> (SELECT datname FROM pg_database WHERE oid = 1680798)) AS "Rollbacks"
>> ) t
>> UNION ALL
>> SELECT 'ti_stats' AS chart_name, row_to_json(t) AS chart_data
>> FROM (SELECT
>>(SELECT sum(tup_inserted) FROM pg_stat_database WHERE datname =
>> (SELECT datname FROM pg_database WHERE oid = 1680798)) AS "Inserts",
>>(SELECT sum(tup_updated) FROM pg_stat_database WHERE datname = (SELECT
>> datname FROM pg_database WHERE oid = 1680798)) AS "Updates",
>>(SELECT sum(tup_deleted) FROM pg_stat_database WHERE datname = (SELECT
>> datname FROM pg_database WHERE oid = 1680798)) AS "Deletes"
>> ) t
>> UNION ALL
>> SELECT 'to_stats' AS chart_name, row_to_json(t) AS chart_data
>> FROM (SELECT
>>(SELECT sum(tup_fetched) FROM pg_stat_database WHERE datname = (SELECT
>> datname FROM pg_database WHERE oid = 1680798)) AS "Fetched",
>>(SELECT sum(tup_returned) FROM pg_stat_database WHERE datname =
>> (SELECT datname FROM pg_database WHERE oid = 1680798)) AS "Returned"
>> ) t
>> UNION ALL
>> SELECT 'bio_stats' AS chart_name, row_to_json(t) AS chart_data
>> FROM (SELECT
>>(SELECT sum(blks_read) FROM pg_stat_database WHERE datname = (SELECT
>> datname FROM pg_database WHERE oid = 1680798)) AS "Reads",
>>(SELECT sum(blks_hit) FROM pg_stat_database WHERE datname = (SELECT
>> datname FROM pg_database WHERE oid = 1680798)) AS "Hits"
>> ) t
>>
>> 2) Can you hard refresh the browser (remove all browser cache & try
>> again) & check for any browser console errors next time when you try to
>> access the dashboard?
>> 3) Can you cross verify in any other browser if the same issue exists?
>>
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>>
>> On Sun, May 3, 2020 at 1:33 AM Shaheed Haque 
>> wrote:
>>
>>> Here is the information requested...
>>>
>>> On Fri, 1 May 2020 at 01:10, Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
>>

Dependencies, and upcoming changes to pip

[Shaheed Haque]

Hi,

I've long wondered why pgAdmin4 seems to hard pin its dependencies;
specifically these two which do seem rather outdated:

pgadmin4 4.26 requires pytz==2018.9, but you'll have pytz 2020.1 which is
incompatible.
pgadmin4 4.26 requires sqlparse==0.2.4, but you'll have sqlparse 0.3.1
which is incompatible.

So far, I've just ignored this , and as far as I know, I have not
encountered any obvious issues. But, with the upcoming changes to pip's
resolver, I suspect this is going to become a hard error for me as I
believe the new resolver will simply abort the install in such cases:

ERROR: After October 2020 you may experience errors when installing or
updating packages. This is because pip will change the way that it resolves
dependency conflicts.

We recommend you use --use-feature=2020-resolver to test your packages with
the new resolver before it becomes the default.

So, I'd like to request that any unneeded constraints are either removed,
or relaxed, or at least updated to something close to current.

Thanks, Shaheed

P.S. We understand about venvs, but we have a whole bunch of dependencies
beyond pgAdmin and having to set up multiple venvs to isolate everything is
a deployment-time overhead we prefer to avoid.

Re: Dependencies, and upcoming changes to pip

[Shaheed Haque]

Hi Akshay,

I noticed that pgAdmin 4.27 updated the dependencies a bit, for which many
thanks. The current situation from my perspective is not quite all roses
yet because I get this:

ERROR: After October 2020 you may experience errors when installing or
updating packages. This is because pip will change the way that it resolves
dependency conflicts.

We recommend you use --use-feature=2020-resolver to test your packages with
the new resolver before it becomes the default.

pgadmin4 4.27 requires sqlparse<0.4,>=0.3.0, but you'll have sqlparse 0.4.1
which is incompatible.

>From reviewing the sqlparse change log, I presume the reason pgAdmin wants
<0.4 is to preserve support for Python 3.4? I'll need to adapt my installer
to deal with pgAdmin separately...unless you are planning to require Python
3.5 and so relax the <0.4 constraint sometime soon.

Is that likely (or should I plan to make the changes)?

Any input appreciated.

Thanks, Shaheed













On Wed, 30 Sep 2020 at 10:27, Akshay Joshi 
wrote:

> Thanks, Shaheed for pointing it out, we will definitely look into it.
>
> On Tue, Sep 29, 2020 at 6:08 PM Shaheed Haque 
> wrote:
>
>> Hi,
>>
>> I've long wondered why pgAdmin4 seems to hard pin its dependencies;
>> specifically these two which do seem rather outdated:
>>
>> pgadmin4 4.26 requires pytz==2018.9, but you'll have pytz 2020.1 which is
>> incompatible.
>> pgadmin4 4.26 requires sqlparse==0.2.4, but you'll have sqlparse 0.3.1
>> which is incompatible.
>>
>> So far, I've just ignored this , and as far as I know, I have not
>> encountered any obvious issues. But, with the upcoming changes to pip's
>> resolver, I suspect this is going to become a hard error for me as I
>> believe the new resolver will simply abort the install in such cases:
>>
>> ERROR: After October 2020 you may experience errors when installing or
>> updating packages. This is because pip will change the way that it resolves
>> dependency conflicts.
>>
>> We recommend you use --use-feature=2020-resolver to test your packages
>> with the new resolver before it becomes the default.
>>
>> So, I'd like to request that any unneeded constraints are either removed,
>> or relaxed, or at least updated to something close to current.
>>
>> Thanks, Shaheed
>>
>> P.S. We understand about venvs, but we have a whole bunch of dependencies
>> beyond pgAdmin and having to set up multiple venvs to isolate everything is
>> a deployment-time overhead we prefer to avoid.
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
> *pgAdmin Hacker | Sr. Software Architect*
> *EDB Postgres <http://edbpostgres.com>*
>
> *Mobile: +91 976-788-8246*
>

Re: Dependencies, and upcoming changes to pip

[Shaheed Haque]

Ok, thanks for the update!

On Tue, 20 Oct 2020 at 08:11, Akshay Joshi 
wrote:

> Hi Shaheed
>
> On Tue, Oct 20, 2020 at 12:09 AM Shaheed Haque 
> wrote:
>
>> Hi Akshay,
>>
>> I noticed that pgAdmin 4.27 updated the dependencies a bit, for which
>> many thanks. The current situation from my perspective is not quite all
>> roses yet because I get this:
>>
>> ERROR: After October 2020 you may experience errors when installing or
>> updating packages. This is because pip will change the way that it resolves
>> dependency conflicts.
>>
>> We recommend you use --use-feature=2020-resolver to test your packages
>> with the new resolver before it becomes the default.
>>
>> pgadmin4 4.27 requires sqlparse<0.4,>=0.3.0, but you'll have sqlparse
>> 0.4.1 which is incompatible.
>>
>> From reviewing the sqlparse change log, I presume the reason pgAdmin
>> wants <0.4 is to preserve support for Python 3.4? I'll need to adapt my
>> installer to deal with pgAdmin separately...unless you are planning to
>> require Python 3.5 and so relax the <0.4 constraint sometime soon.
>>
>> Is that likely (or should I plan to make the changes)?
>>
>> Any input appreciated.
>>
>
>We have used *pgcli* code for autocompletion in pgAdmin4 and we pick
> this setting from https://github.com/dbcli/pgcli/blob/master/setup.py. As
> they haven't tested their code with the latest version of sqlparse we
> should not change it.
>
>>
>> Thanks, Shaheed
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, 30 Sep 2020 at 10:27, Akshay Joshi 
>> wrote:
>>
>>> Thanks, Shaheed for pointing it out, we will definitely look into it.
>>>
>>> On Tue, Sep 29, 2020 at 6:08 PM Shaheed Haque 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've long wondered why pgAdmin4 seems to hard pin its dependencies;
>>>> specifically these two which do seem rather outdated:
>>>>
>>>> pgadmin4 4.26 requires pytz==2018.9, but you'll have pytz 2020.1 which
>>>> is incompatible.
>>>> pgadmin4 4.26 requires sqlparse==0.2.4, but you'll have sqlparse 0.3.1
>>>> which is incompatible.
>>>>
>>>> So far, I've just ignored this , and as far as I know, I have not
>>>> encountered any obvious issues. But, with the upcoming changes to pip's
>>>> resolver, I suspect this is going to become a hard error for me as I
>>>> believe the new resolver will simply abort the install in such cases:
>>>>
>>>> ERROR: After October 2020 you may experience errors when installing or
>>>> updating packages. This is because pip will change the way that it resolves
>>>> dependency conflicts.
>>>>
>>>> We recommend you use --use-feature=2020-resolver to test your packages
>>>> with the new resolver before it becomes the default.
>>>>
>>>> So, I'd like to request that any unneeded constraints are either
>>>> removed, or relaxed, or at least updated to something close to current.
>>>>
>>>> Thanks, Shaheed
>>>>
>>>> P.S. We understand about venvs, but we have a whole bunch of
>>>> dependencies beyond pgAdmin and having to set up multiple venvs to isolate
>>>> everything is a deployment-time overhead we prefer to avoid.
>>>>
>>>
>>>
>>> --
>>> *Thanks & Regards*
>>> *Akshay Joshi*
>>> *pgAdmin Hacker | Sr. Software Architect*
>>> *EDB Postgres <http://edbpostgres.com>*
>>>
>>> *Mobile: +91 976-788-8246*
>>>
>>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
> *pgAdmin Hacker | Sr. Software Architect*
> *EDB Postgres <http://edbpostgres.com>*
>
> *Mobile: +91 976-788-8246*
>

Re: Dependencies, and upcoming changes to pip

[Shaheed Haque]

It looks like pgcli has changed (https://github.com/dbcli/pgcli/pull/1224)
ahead of the upcoming pip 21 release (but I'm not sure what their release
plans are).

On Tue, 20 Oct 2020 at 23:28, Shaheed Haque  wrote:

> Ok, thanks for the update!
>
> On Tue, 20 Oct 2020 at 08:11, Akshay Joshi 
> wrote:
>
>> Hi Shaheed
>>
>> On Tue, Oct 20, 2020 at 12:09 AM Shaheed Haque 
>> wrote:
>>
>>> Hi Akshay,
>>>
>>> I noticed that pgAdmin 4.27 updated the dependencies a bit, for which
>>> many thanks. The current situation from my perspective is not quite all
>>> roses yet because I get this:
>>>
>>> ERROR: After October 2020 you may experience errors when installing or
>>> updating packages. This is because pip will change the way that it resolves
>>> dependency conflicts.
>>>
>>> We recommend you use --use-feature=2020-resolver to test your packages
>>> with the new resolver before it becomes the default.
>>>
>>> pgadmin4 4.27 requires sqlparse<0.4,>=0.3.0, but you'll have sqlparse
>>> 0.4.1 which is incompatible.
>>>
>>> From reviewing the sqlparse change log, I presume the reason pgAdmin
>>> wants <0.4 is to preserve support for Python 3.4? I'll need to adapt my
>>> installer to deal with pgAdmin separately...unless you are planning to
>>> require Python 3.5 and so relax the <0.4 constraint sometime soon.
>>>
>>> Is that likely (or should I plan to make the changes)?
>>>
>>> Any input appreciated.
>>>
>>
>>We have used *pgcli* code for autocompletion in pgAdmin4 and we pick
>> this setting from https://github.com/dbcli/pgcli/blob/master/setup.py.
>> As they haven't tested their code with the latest version of sqlparse we
>> should not change it.
>>
>>>
>>> Thanks, Shaheed
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 30 Sep 2020 at 10:27, Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
>>>> Thanks, Shaheed for pointing it out, we will definitely look into it.
>>>>
>>>> On Tue, Sep 29, 2020 at 6:08 PM Shaheed Haque 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've long wondered why pgAdmin4 seems to hard pin its dependencies;
>>>>> specifically these two which do seem rather outdated:
>>>>>
>>>>> pgadmin4 4.26 requires pytz==2018.9, but you'll have pytz 2020.1 which
>>>>> is incompatible.
>>>>> pgadmin4 4.26 requires sqlparse==0.2.4, but you'll have sqlparse 0.3.1
>>>>> which is incompatible.
>>>>>
>>>>> So far, I've just ignored this , and as far as I know, I have not
>>>>> encountered any obvious issues. But, with the upcoming changes to pip's
>>>>> resolver, I suspect this is going to become a hard error for me as I
>>>>> believe the new resolver will simply abort the install in such cases:
>>>>>
>>>>> ERROR: After October 2020 you may experience errors when installing or
>>>>> updating packages. This is because pip will change the way that it 
>>>>> resolves
>>>>> dependency conflicts.
>>>>>
>>>>> We recommend you use --use-feature=2020-resolver to test your packages
>>>>> with the new resolver before it becomes the default.
>>>>>
>>>>> So, I'd like to request that any unneeded constraints are either
>>>>> removed, or relaxed, or at least updated to something close to current.
>>>>>
>>>>> Thanks, Shaheed
>>>>>
>>>>> P.S. We understand about venvs, but we have a whole bunch of
>>>>> dependencies beyond pgAdmin and having to set up multiple venvs to isolate
>>>>> everything is a deployment-time overhead we prefer to avoid.
>>>>>
>>>>
>>>>
>>>> --
>>>> *Thanks & Regards*
>>>> *Akshay Joshi*
>>>> *pgAdmin Hacker | Sr. Software Architect*
>>>> *EDB Postgres <http://edbpostgres.com>*
>>>>
>>>> *Mobile: +91 976-788-8246*
>>>>
>>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>> *pgAdmin Hacker | Sr. Software Architect*
>> *EDB Postgres <http://edbpostgres.com>*
>>
>> *Mobile: +91 976-788-8246*
>>
>

Re: Dependencies, and upcoming changes to pip

[Shaheed Haque]

This has been released. Please consider relaxing your dependencies
accordingly...

On Wed, 2 Dec 2020 at 10:04, Shaheed Haque  wrote:

> It looks like pgcli has changed (https://github.com/dbcli/pgcli/pull/1224)
> ahead of the upcoming pip 21 release (but I'm not sure what their release
> plans are).
>
> On Tue, 20 Oct 2020 at 23:28, Shaheed Haque 
> wrote:
>
>> Ok, thanks for the update!
>>
>> On Tue, 20 Oct 2020 at 08:11, Akshay Joshi 
>> wrote:
>>
>>> Hi Shaheed
>>>
>>> On Tue, Oct 20, 2020 at 12:09 AM Shaheed Haque 
>>> wrote:
>>>
>>>> Hi Akshay,
>>>>
>>>> I noticed that pgAdmin 4.27 updated the dependencies a bit, for which
>>>> many thanks. The current situation from my perspective is not quite all
>>>> roses yet because I get this:
>>>>
>>>> ERROR: After October 2020 you may experience errors when installing or
>>>> updating packages. This is because pip will change the way that it resolves
>>>> dependency conflicts.
>>>>
>>>> We recommend you use --use-feature=2020-resolver to test your packages
>>>> with the new resolver before it becomes the default.
>>>>
>>>> pgadmin4 4.27 requires sqlparse<0.4,>=0.3.0, but you'll have sqlparse
>>>> 0.4.1 which is incompatible.
>>>>
>>>> From reviewing the sqlparse change log, I presume the reason pgAdmin
>>>> wants <0.4 is to preserve support for Python 3.4? I'll need to adapt my
>>>> installer to deal with pgAdmin separately...unless you are planning to
>>>> require Python 3.5 and so relax the <0.4 constraint sometime soon.
>>>>
>>>> Is that likely (or should I plan to make the changes)?
>>>>
>>>> Any input appreciated.
>>>>
>>>
>>>We have used *pgcli* code for autocompletion in pgAdmin4 and we pick
>>> this setting from https://github.com/dbcli/pgcli/blob/master/setup.py.
>>> As they haven't tested their code with the latest version of sqlparse we
>>> should not change it.
>>>
>>>>
>>>> Thanks, Shaheed
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 30 Sep 2020 at 10:27, Akshay Joshi <
>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>
>>>>> Thanks, Shaheed for pointing it out, we will definitely look into it.
>>>>>
>>>>> On Tue, Sep 29, 2020 at 6:08 PM Shaheed Haque 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've long wondered why pgAdmin4 seems to hard pin its dependencies;
>>>>>> specifically these two which do seem rather outdated:
>>>>>>
>>>>>> pgadmin4 4.26 requires pytz==2018.9, but you'll have pytz 2020.1
>>>>>> which is incompatible.
>>>>>> pgadmin4 4.26 requires sqlparse==0.2.4, but you'll have sqlparse
>>>>>> 0.3.1 which is incompatible.
>>>>>>
>>>>>> So far, I've just ignored this , and as far as I know, I have not
>>>>>> encountered any obvious issues. But, with the upcoming changes to pip's
>>>>>> resolver, I suspect this is going to become a hard error for me as I
>>>>>> believe the new resolver will simply abort the install in such cases:
>>>>>>
>>>>>> ERROR: After October 2020 you may experience errors when installing
>>>>>> or updating packages. This is because pip will change the way that it
>>>>>> resolves
>>>>>> dependency conflicts.
>>>>>>
>>>>>> We recommend you use --use-feature=2020-resolver to test your
>>>>>> packages with the new resolver before it becomes the default.
>>>>>>
>>>>>> So, I'd like to request that any unneeded constraints are either
>>>>>> removed, or relaxed, or at least updated to something close to current.
>>>>>>
>>>>>> Thanks, Shaheed
>>>>>>
>>>>>> P.S. We understand about venvs, but we have a whole bunch of
>>>>>> dependencies beyond pgAdmin and having to set up multiple venvs to 
>>>>>> isolate
>>>>>> everything is a deployment-time overhead we prefer to avoid.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Thanks & Regards*
>>>>> *Akshay Joshi*
>>>>> *pgAdmin Hacker | Sr. Software Architect*
>>>>> *EDB Postgres <http://edbpostgres.com>*
>>>>>
>>>>> *Mobile: +91 976-788-8246*
>>>>>
>>>>
>>>
>>> --
>>> *Thanks & Regards*
>>> *Akshay Joshi*
>>> *pgAdmin Hacker | Sr. Software Architect*
>>> *EDB Postgres <http://edbpostgres.com>*
>>>
>>> *Mobile: +91 976-788-8246*
>>>
>>

Re: Dependencies, and upcoming changes to pip

[Shaheed Haque]

Great, thanks!

On Mon, 14 Dec 2020, 07:06 Akshay Joshi, 
wrote:

> Thanks, Shaheed
>
> Updated the version.
>
> On Sat, Dec 12, 2020 at 5:24 PM Shaheed Haque 
> wrote:
>
>> This has been released. Please consider relaxing your dependencies
>> accordingly...
>>
>> On Wed, 2 Dec 2020 at 10:04, Shaheed Haque 
>> wrote:
>>
>>> It looks like pgcli has changed (
>>> https://github.com/dbcli/pgcli/pull/1224) ahead of the upcoming pip 21
>>> release (but I'm not sure what their release plans are).
>>>
>>> On Tue, 20 Oct 2020 at 23:28, Shaheed Haque 
>>> wrote:
>>>
>>>> Ok, thanks for the update!
>>>>
>>>> On Tue, 20 Oct 2020 at 08:11, Akshay Joshi <
>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Shaheed
>>>>>
>>>>> On Tue, Oct 20, 2020 at 12:09 AM Shaheed Haque 
>>>>> wrote:
>>>>>
>>>>>> Hi Akshay,
>>>>>>
>>>>>> I noticed that pgAdmin 4.27 updated the dependencies a bit, for which
>>>>>> many thanks. The current situation from my perspective is not quite all
>>>>>> roses yet because I get this:
>>>>>>
>>>>>> ERROR: After October 2020 you may experience errors when installing
>>>>>> or updating packages. This is because pip will change the way that it
>>>>>> resolves
>>>>>> dependency conflicts.
>>>>>>
>>>>>> We recommend you use --use-feature=2020-resolver to test your
>>>>>> packages with the new resolver before it becomes the default.
>>>>>>
>>>>>> pgadmin4 4.27 requires sqlparse<0.4,>=0.3.0, but you'll have sqlparse
>>>>>> 0.4.1 which is incompatible.
>>>>>>
>>>>>> From reviewing the sqlparse change log, I presume the reason pgAdmin
>>>>>> wants <0.4 is to preserve support for Python 3.4? I'll need to adapt my
>>>>>> installer to deal with pgAdmin separately...unless you are planning to
>>>>>> require Python 3.5 and so relax the <0.4 constraint sometime soon.
>>>>>>
>>>>>> Is that likely (or should I plan to make the changes)?
>>>>>>
>>>>>> Any input appreciated.
>>>>>>
>>>>>
>>>>>We have used *pgcli* code for autocompletion in pgAdmin4 and we
>>>>> pick this setting from
>>>>> https://github.com/dbcli/pgcli/blob/master/setup.py. As they haven't
>>>>> tested their code with the latest version of sqlparse we should not change
>>>>> it.
>>>>>
>>>>>>
>>>>>> Thanks, Shaheed
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 30 Sep 2020 at 10:27, Akshay Joshi <
>>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> Thanks, Shaheed for pointing it out, we will definitely look into
>>>>>>> it.
>>>>>>>
>>>>>>> On Tue, Sep 29, 2020 at 6:08 PM Shaheed Haque <
>>>>>>> shaheedha...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've long wondered why pgAdmin4 seems to hard pin its dependencies;
>>>>>>>> specifically these two which do seem rather outdated:
>>>>>>>>
>>>>>>>> pgadmin4 4.26 requires pytz==2018.9, but you'll have pytz 2020.1
>>>>>>>> which is incompatible.
>>>>>>>> pgadmin4 4.26 requires sqlparse==0.2.4, but you'll have sqlparse
>>>>>>>> 0.3.1 which is incompatible.
>>>>>>>>
>>>>>>>> So far, I've just ignored this , and as far as I know, I have not
>>>>>>>> encountered any obvious issues. But, with the upcoming changes to pip's
>>>>>>>> resolver, I suspect this is going to become a hard error for me as I
>>>>>>>> believe the new resolver will simply abort the install in such cases:
>>>>>>>>
>>>>>>>> ERROR: After October 2020 you may experience errors when installing
>>>>>>>> or updating packages. This is because pip will change the way that it
>>>>>>>> resolves
>>>>>>>> dependency conflicts.
>>>>>>>>
>>>>>>>> We recommend you use --use-feature=2020-resolver to test your
>>>>>>>> packages with the new resolver before it becomes the default.
>>>>>>>>
>>>>>>>> So, I'd like to request that any unneeded constraints are either
>>>>>>>> removed, or relaxed, or at least updated to something close to current.
>>>>>>>>
>>>>>>>> Thanks, Shaheed
>>>>>>>>
>>>>>>>> P.S. We understand about venvs, but we have a whole bunch of
>>>>>>>> dependencies beyond pgAdmin and having to set up multiple venvs to 
>>>>>>>> isolate
>>>>>>>> everything is a deployment-time overhead we prefer to avoid.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Thanks & Regards*
>>>>>>> *Akshay Joshi*
>>>>>>> *pgAdmin Hacker | Sr. Software Architect*
>>>>>>> *EDB Postgres <http://edbpostgres.com>*
>>>>>>>
>>>>>>> *Mobile: +91 976-788-8246*
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> *Thanks & Regards*
>>>>> *Akshay Joshi*
>>>>> *pgAdmin Hacker | Sr. Software Architect*
>>>>> *EDB Postgres <http://edbpostgres.com>*
>>>>>
>>>>> *Mobile: +91 976-788-8246*
>>>>>
>>>>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
> *pgAdmin Hacker | Principal Software Architect*
> *EDB Postgres <http://edbpostgres.com>*
>
> *Mobile: +91 976-788-8246*
>

Possible packaging problem with gssapi

[Shaheed Haque]

Hi,

I *think* there is something not quite right with the pgAdmin4 packaging as
regards gssapi, which I assume is related to the new Kerberos support in
4.30. When I try to deploy our software, which has a dependency on
pgAdmin4, I see something like this:

$ sudo pip install ...blah...our stuff...blah...
...
Collecting pgadmin4
 Downloading pgadmin4-5.0-py3-none-any.whl (97.3 MB)
...
Collecting gssapi==1.6.*
 Downloading gssapi-1.6.12.tar.gz (1.1 MB)
   ERROR: Command errored out with exit status 1:
...
   /bin/sh: 1: krb5-config: not found
   In distributed package, building from C files...
  ...
   subprocess.CalledProcessError: Command 'krb5-config --libs gssapi'
returned non-zero exit status 127.
   
WARNING: Discarding
https://files.pythonhosted.org/packages/c2/77/7cba9c5945d4d42d54ed1fb2a0bd8095d629548743198fa47ed6c1167846/gssapi-1.6.12.tar.gz#sha256=16ed3b5d7fc37683be27f34a2a6
5062cb11d815d019bb2e89ffeb395576e51c8 (from https://pypi.org/simple/gssapi/)
(requires-python:>=3.6.*). Command errored out with exit status 1: python
setup.py egg_info Check the logs for full command output.
 Downloading gssapi-1.6.11.tar.gz (1.1 MB)
...same error..
 Downloading gssapi-1.6.10.tar.gz (1.1 MB)
...same error..
 Downloading gssapi-1.6.9.tar.gz (1.1 MB)
...same error..
 Downloading gssapi-1.6.5.tar.gz (1.1 MB)
...same error..
 Downloading gssapi-1.6.2.tar.gz (1.1 MB)
...same error..
 Downloading gssapi-1.6.1.tar.gz (1.1 MB)
...same error..
 Downloading gssapi-1.6.0.tar.gz (1.1 MB)
...same error..
Collecting pgadmin4
 Downloading pgadmin4-4.30-py3-none-any.whl (92.7 MB)

At some level, this is a dependency issue for gsslib, not pgadmin4, but
OTOH, I'm not using Kerberos so it is kind of annoying.

[What is worse is that, because - I think - of the dependency pinning
approach that pgAdmin4 uses, the above downgrade to pgadmin4.30 is not the
end of the story: I actually end up all the way back on pgadmin4.25, which
is even more annoying, if not downright dangerous].

I'm not sure if there is a way to make the gsslib dependency
optional/failsafe?

Thanks, Shaheed

Re: Possible packaging problem with gssapi

[Shaheed Haque]

Hi,

On Wed, 3 Mar 2021 at 14:42, Dave Page  wrote:

> Hi
>
> On Wed, Mar 3, 2021 at 2:33 PM Shaheed Haque 
> wrote:
>
>> Hi,
>>
>> I *think* there is something not quite right with the pgAdmin4 packaging
>> as regards gssapi, which I assume is related to the new Kerberos support in
>> 4.30. When I try to deploy our software, which has a dependency on
>> pgAdmin4, I see something like this:
>>
>> $ sudo pip install ...blah...our stuff...blah...
>> ...
>> Collecting pgadmin4
>>  Downloading pgadmin4-5.0-py3-none-any.whl (97.3 MB)
>> ...
>> Collecting gssapi==1.6.*
>>  Downloading gssapi-1.6.12.tar.gz (1.1 MB)
>>ERROR: Command errored out with exit status 1:
>> ...
>>/bin/sh: 1: krb5-config: not found
>>In distributed package, building from C files...
>>   ...
>>subprocess.CalledProcessError: Command 'krb5-config --libs gssapi'
>> returned non-zero exit status 127.
>>
>> WARNING: Discarding
>> https://files.pythonhosted.org/packages/c2/77/7cba9c5945d4d42d54ed1fb2a0bd8095d629548743198fa47ed6c1167846/gssapi-1.6.12.tar.gz#sha256=16ed3b5d7fc37683be27f34a2a6
>> 5062cb11d815d019bb2e89ffeb395576e51c8 (from
>> https://pypi.org/simple/gssapi/) (requires-python:>=3.6.*). Command
>> errored out with exit status 1: python setup.py egg_info Check the logs for
>> full command output.
>>  Downloading gssapi-1.6.11.tar.gz (1.1 MB)
>> ...same error..
>>  Downloading gssapi-1.6.10.tar.gz (1.1 MB)
>> ...same error..
>>  Downloading gssapi-1.6.9.tar.gz (1.1 MB)
>> ...same error..
>>  Downloading gssapi-1.6.5.tar.gz (1.1 MB)
>> ...same error..
>>  Downloading gssapi-1.6.2.tar.gz (1.1 MB)
>> ...same error..
>>  Downloading gssapi-1.6.1.tar.gz (1.1 MB)
>> ...same error..
>>  Downloading gssapi-1.6.0.tar.gz (1.1 MB)
>> ...same error..
>> Collecting pgadmin4
>>  Downloading pgadmin4-4.30-py3-none-any.whl (92.7 MB)
>>
>> At some level, this is a dependency issue for gsslib, not pgadmin4, but
>> OTOH, I'm not using Kerberos so it is kind of annoying.
>>
>
> Right - it is caused by gssapi, which will be built from source if there's
> no binary wheel available for your platform. It's not clear what platform
> you're on, but installing the krb5-devel (Redhat/CentOS/Fedora)
> or libkrb5-dev (Debian/Ubuntu) should solve the build issue.
>

Yes, I'm on Ubuntu LTS, and installing one of the krb dev packages does
indeed solve the problem. Ideally though, I'd like to avoid installing a
package we don't - in principle - need.


>
>> [What is worse is that, because - I think - of the dependency pinning
>> approach that pgAdmin4 uses, the above downgrade to pgadmin4.30 is not the
>> end of the story: I actually end up all the way back on pgadmin4.25, which
>> is even more annoying, if not downright dangerous].
>>
>
> I'm not sure I understand the issue there. What prevents you from going
> back to 4.29?
>

That's not clear to me, and I don't know if there is an accessible way to
work out why pip3's dependency resolver (which I guess is in charge here)
decides that it has to go back further. I can post logs or run any commands
that might help track this down, but I fear this is inevitable if packages
we depend on extensively pin dependencies.

FWIW, pgadmin4 and one or two others from a well-known cloud vendor are the
main ones that do extensive pinning. (I can understand why, if one thinks
of oneself as an end product, this might seem attractive, but for me,
pgadmin4 is a rather useful component, not the end application :-)).


>
>> I'm not sure if there is a way to make the gsslib dependency
>> optional/failsafe?
>>
>
> I'd need to dive into it some more. There are "extras", but from what I
> can see these have to be explicitly installed. Ideally we want something
> that will try to install gssapi automatically, but not get upset if it
> fails.
>

As noted, I'm not trying to pin any blame for this, and there are
workarounds available. But anything that you might do to help would be
great.

Thanks for the quick reply (as always!),

Shaheed


> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: http://www.enterprisedb.com
>
>