On Wed, Mar 20, 2019 at 12:21 PM Khushboo Vashi < [email protected]> wrote:
> > > On Wed, Mar 20, 2019 at 5:49 PM Dave Page <[email protected]> wrote: > >> >> >> On Wed, Mar 20, 2019 at 12:11 PM Khushboo Vashi < >> [email protected]> wrote: >> >>> >>> >>> On Wed, Mar 20, 2019 at 4:54 PM Dave Page <[email protected]> wrote: >>> >>>> Hi >>>> >>>> On Wed, Mar 20, 2019 at 9:50 AM Shaheed Haque <[email protected]> >>>> wrote: >>>> >>>>> My goodness... >>>>> >>>> >>>> Indeed. >>>> >>>> >>>>> >>>>> On Wed, 20 Mar 2019 at 09:18, Dave Page <[email protected]> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Wed, Mar 20, 2019 at 6:18 AM Khushboo Vashi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 19, 2019 at 10:24 PM Dave Page <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 19, 2019 at 1:37 PM Shaheed Haque <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Tue, 19 Mar 2019 at 10:28, Dave Page <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> On Tue, Mar 19, 2019 at 10:19 AM Shaheed Haque < >>>>>>>>>> [email protected]> 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
