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 <srha...@theiet.org> 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 <dp...@pgadmin.org> 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 <dp...@pgadmin.org> 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 <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Wed, Mar 20, 2019 at 9:50 AM Shaheed Haque <srha...@theiet.org> >>>>>> wrote: >>>>>> >>>>>>> My goodness... >>>>>>> >>>>>> >>>>>> Indeed. >>>>>> >>>>>> >>>>>>> >>>>>>> On Wed, 20 Mar 2019 at 09:18, Dave Page <dp...@pgadmin.org> 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 <dp...@pgadmin.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 19, 2019 at 1:37 PM Shaheed Haque <srha...@theiet.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Tue, 19 Mar 2019 at 10:28, Dave Page <dp...@pgadmin.org> >>>>>>>>>>> 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 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... >>>>>>> >>>>>> >>>>>> I added a request to the discussion at >>>>>> https://github.com/psycopg/psycopg2/issues/674 to have the warning >>>>>> removed. I doubt it'll be successful though, so I wouldn't hold your >>>>>> breath. >>>>>> >>>>>> If we build our own Python, libpq etc, then why can't we use >>>>> *--no-binary* option in the requirements.txt? >>>>> >>>>>> >>>> That won't prevent the warning at runtime will it? >>>> >>> This warning arrives only in case of binary. So, if we install the >>> package with --no-binary option then, it will disappear. >>> >> >> Hmm, yes - so it does. Let me think about the ramifications of doing that. >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >
