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
Thanks, Shaheed for pointing it out, we will definitely look into it.
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 PostgresMobile: +91 976-788-8246