Re: Noisy dependency on psycopg2 versus psycopg2-binary

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 <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wed, Mar 20, 2019 at 12:21 PM Khushboo Vashi <
> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> On Wed, Mar 20, 2019 at 5:49 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>>
>>> On Wed, Mar 20, 2019 at 12:11 PM Khushboo Vashi <
>>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>
>>>>
>>>>
>>>> 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?
>>>>
>>>>>
>>> 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
>