Re: [pgadmin-hackers] Last few steps for pgadmin4 on RHEL 6 - Mailing list pgadmin-hackers

On Sun, Mar 19, 2017 at 1:41 PM, Magnus Hagander <magnus@hagander.net> wrote:
>
>
> On Sun, Mar 19, 2017 at 2:33 PM, Devrim Gündüz <devrim@gunduz.org> wrote:
>>
>>
>> Hi,
>>
>> On Fri, 2017-03-17 at 09:40 +0000, Dave Page wrote:
>> > Hmm. That might be tricky. It might work if you just install it into
>> > the web/ directory.
>>
>> If we can make sure that it works, I can rename all packages (like
>> pgadmin4-
>> python-crypto), edit spec files, install them under the web/ directory.
>> This
>> will prevent the breakage that I mentioned at the end of this email.
>>
>> > Is the default version actually too old?
>>
>> It is 2.0.1 on RHEL 6 (vs 2.6.1 on RHEL 7, which is the version that I
>> also
>> used in the PGDG updated packages), and I'm seeing 2.6.1 in the
>> requirements.txt file.
>>
>> > It's quite possible it will work, but we just haven't tested back that
>> > far.
>> > The version numbers in requirements.txt are really just what we know
>> > works,
>> > rather than what actually will in many cases.
>>
>> Just a FYI -- this is the list of the packages that I either added to RHEL
>> 6
>> (via PGDG repo, not EPEL), or updated to a new version:
>>
>> python-beautifulsoup4
>> python-blinker
>> python-crypto
>> python-dateutil
>> python-fixtures
>> python-flask
>> python-flask-babel
>> python-flask-gravatar
>> python-flask-htmlmin
>> python-flask-login
>> python-flask-mail
>> python-flask-principal
>> python-flask-security
>> python-flask-sqlalchemy
>> python-flask-wtf
>> python-html5lib
>> python-htmlmin
>> python-importlib
>> python-itsdangerous
>> python-jinja2
>> python-markupsafe
>> python-mimeparse
>> python-passlib
>> python-pbr
>> python-pyrsistent
>> python-simplejson
>> python-speaklater
>> python-sqlalchemy
>> python-sqlparse
>> python-werkzeug
>> python-wsgiref
>> python-wtforms
>>
>> At this point, I'm seriously considering to invent another sub-repo, at
>> least
>> to host these python dependencies, if installing under web/ won't work.
>> The
>> Python packages are purely static, and won't be updated frequently enough.
>> We
>> can host the main pgadmin4 package in our repo, but then it will be users'
>> responsibility to install the dependencies by using our repo, which may
>> break
>> their systems (or not, no idea)
>>
>
> Yikes. Yeah you definitely do *not* want to have new versions of all those
> packages show up on peoples systems by default, that'll break a whole lot of
> things.

+<several hundred>

> I don't think keeping them in a separate repository is really going to work
> either -- it will still cause the breakage for anybody who wants to use
> pgadmin4.

Yeah.

> The reasonable thing would be to install them locally in the pgadmin4
> package (or in a pgadmin4-dependencies or whatever you want to call it), in
> a way that they are not used by any other software on the system. If that's
> not possible, I think you're just going to have to declare RHEL6 as
> unsupported for it. But surely most or all of that can run inside a
> virtualenv together with the pgadmin code, so I would be surprised if they
> cannot be installed locally.
>
> Finally, I think you need to be careful about calling them "purely static".
> Several of those will need to be monitored for security updates and new
> versions pushed when those show up, if you end up bundling them. Especially
> important if pgadmin4 is used in server mode, but there's definitely things
> in there that would be critical to make sure they're updated for desktop
> mode as well.

I think the first question to answer is, of the packages that already
exist in Centos/EPEL, which ones are actually too old to be used?

As I mentioned earlier in the thread, the version numbers in our
requirements.txt file are really just "the oldest versions we're tried
and know work" rather than a definitive list of absolute minimum
versions.

It may be that in reality, there are no problems, or that it's just
one or two packages that we need newer versions of.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company