Thanks Murtuza.
Do you think the requirement for psutil could at least be relaxed to
5.0.1, the version that ships with Debian Stable?
For my segfault - turns out it's due to the psycopg2/libpq/libssl
issue in psycopg2 ticket #543. So, nothing related to pgadmin4.
(resending to cc the mailing list)
On Thu, Nov 8, 2018 at 6:19 AM Murtuza Zabuawala
<murtuza.zabuawala@enterprisedb.com> wrote:
>
> Hi,
>
> We need psutil to handle backend process management, ie allow the user to terminate long-running backup or restore
job.I don't see any alternative to psutil at a moment which supports cross-platform process management like psutil do.
>
> I think the reason why there is no binary wheel is that it is hard to maintain platform specific binary wheels.
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
> On Thu, Nov 8, 2018 at 6:02 AM David Gilman <davidgilman1@gmail.com> wrote:
>>
>> It looks like the most recent release of pgadmin4, 3.5, added a dependency on
>> psutil==5.4.7 . This dependency is a bit painful, especially for me,
>> for a few reasons.
>>
>> First, it needs a C compiler to build. Second, upstream is not
>> providing a Linux binary wheel, manylinux or not, to help us out here.
>> Third, Debian stable ships with psutil 5.0.1 but you have a hard
>> requirement on 5.4.7. Finally, I tried building my own wheel on what I
>> thought was a similar system but my pgadmin4/apache is segfaulting
>> (although this may not be the fault of pgadmin4, I am unable to rule
>> this out).
>>
>> So I'd appreciate some feedback here, if you happen to know what the
>> best way to troubleshoot this segfault in pgadmin4 that would be
>> great. But for sure I would also ask you to consider relaxing the
>> dependency on psutil given that virtually all users of your package
>> now have to maintain a compiler and wheel compilation toolchain
>> somewhere if they want to run pgadmin4 on Linux.
>>
--
David Gilman
:DG<