Re: Noisy dependency on psycopg2 versus psycopg2-binary

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 <srhaque(at)theiet(dot)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 <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
>>
>