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? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
