Re: Noisy dependency on psycopg2 versus psycopg2-binary

On Wed, Mar 20, 2019 at 4:54 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Wed, Mar 20, 2019 at 9:50 AM Shaheed Haque <srhaque(at)theiet(dot)org> wrote:
>
>> My goodness...
>>
>
> Indeed.
>
>
>>
>> On Wed, 20 Mar 2019 at 09:18, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Wed, Mar 20, 2019 at 6:18 AM Khushboo Vashi <
>>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Mar 19, 2019 at 10:24 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 19, 2019 at 1:37 PM Shaheed Haque <srhaque(at)theiet(dot)org>
>>>>> wrote:
>>>>>
>>>>>> On Tue, 19 Mar 2019 at 10:28, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Tue, Mar 19, 2019 at 10:19 AM Shaheed Haque <srhaque(at)theiet(dot)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?

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