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.

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

Reply via email to