Re: Patch for pgAdmin4 RPM package

Hi

On Tue, Jun 7, 2016 at 8:02 AM, Sandeep Thakkar <
sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:

> Hi Dave
>
> I used few APIs from Importing Modules and Modules Objects to import the
> pgAdmin4 module and then get it's location but the application crashed on
> running. I didn't debug it and instead created a new function in Server.cpp
> to get the python path and the webpath which uses python command. If we
> still need to use the Python/C APIs then that would take some more time as
> nobody has expertise on that. :(
>
> Please find the patch attached. Web RPM will install an empty file
> pgadmin4-v1.conf in "<pgadmin4-web-v1>/etc/httpd/conf.d/". I thought this
> file must be present in the sources or must be generated after build, but I
> didn't find any. So, I created an empty file.
>

I still think we're making this too difficult. We know what the standard
version of Python is on each supported platform, and therefore we know
where to find it's site-packages directory. We could add a global config
file to the runtime (/etc/pgadmin4/runtime.ini or similar), so the search
for the web app and the runtime environments can fall back to values in
there.

Thoughts?

Other comments:

- You can drop the changes to conf.py - we're no longer using that doc
template.

- This is the link for the current source tarball:
https://ftp.postgresql.org/pub/pgadmin3/pgadmin4/v1.0-beta1/src/pgadmin4-1.0-beta1.tar.gz

- "BuildRequires: python-sphinx_rtd_theme" and similar can also go.

>
>
> On Mon, Jun 6, 2016 at 2:47 PM, Ashesh Vashi <
> ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>> On Mon, Jun 6, 2016 at 2:44 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hmm, virtualenv's a good point.
>>>
>>> I wonder if for the RPMs (and DEBs) we're just trying too hard. Is there
>>> any good reason to support SxS there? Stability I suppose, but then we
>>> don't support back-branches long term anyway.
>>>
>> pgAdmin IV may need particular version of third party libraries.
>> We may not control over, what other application will require.
>>
>> Hence - it can create dependency issue.
>>
>>>
>>> Does anyone think we need to support side-by-side RPM/DEB installation
>>> of multiple major versions of pgAdmin? Devrim? Hamid?
>>>
>> I do not feel the requirement of it.
>>
>>
>> --
>>
>> Thanks & Regards,
>>
>> Ashesh Vashi
>> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>> <http://www.enterprisedb.com/>
>>
>>
>> *http://www.linkedin.com/in/asheshvashi*
>> <http://www.linkedin.com/in/asheshvashi>
>>
>>>
>>> The config file would be part of the web package.
>>>
>>> On Mon, Jun 6, 2016 at 10:09 AM, Sandeep Thakkar <
>>> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>>>
>>>> I already asked them about the APIs, though I didn't ask them about
>>>> what is the best way to handle SxS installation. Will check with them.
>>>>
>>>> PIP package for pgadmin4 doesn't support SxS as it creates the
>>>> directory with the name 'pgadmin4' only. Googling about the SxS with PIP
>>>> says that people use virtualenv to achieve it.
>>>>
>>>> Regarding pgadmin4-v1.conf - will it be a part of pgadmin4-docs RPM?
>>>> Needed for Debian also?
>>>>
>>>> On Mon, Jun 6, 2016 at 1:53 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>> I have no idea. I would ask one of the Python guru's sitting next to
>>>>> you (as well as whether the way we'd handle side-by-side packages is
>>>>> appropriate). Also, look at what the PIP package does (does that even work
>>>>> properly in a SxS scenario? I don't know if we thought to check that).
>>>>>
>>>>> BTW; on the RPMs - we also need to include a config snippet for
>>>>> Apache, e.g. /etc/httpd/conf.d/pgadmin4-v1.conf. The online docs for
>>>>> pgAdmin have a section on configuring that.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 6, 2016 at 9:15 AM, Sandeep Thakkar <
>>>>> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>>>>>
>>>>>> Yeah, I got the point. To distinguish between v1 and v2, we can have
>>>>>> blank __init__.py in the v1 and v2 directories. I tried it and could
>>>>>> successfully import the pgAdmin4 using "import pgadmin4_web_v1.pgAdmin4"
>>>>>> and "import pgadmin4_web_v2.pgAdmin4". Please note that I had to rename
>>>>>> hyphen to underscore in the directories to achieve this.
>>>>>>
>>>>>> But, I spent enough time to find the API that can get me the location
>>>>>> for "pgadmin4_web_v1.pgAdmin4" module, but couldn't find it. Do you have an
>>>>>> idea?
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 3, 2016 at 8:24 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>>
>>>>>>> My point is that the runtime uses the platform supplied Python
>>>>>>> interpreter, which presumably knows where to search for packages. Mind you,
>>>>>>> I suppose the issue there is that it wouldn't be able to distinguish
>>>>>>> between v1 and v2 then...
>>>>>>>
>>>>>>> I don't have a major issue with your suggested code - I just want to
>>>>>>> make sure we need it.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 3, 2016 at 3:39 PM, Sandeep Thakkar <
>>>>>>> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>>>>>>>
>>>>>>>> Do you mean to say when a python app is launched, it imports some
>>>>>>>> modules automatically and in that sense it knows about where it's
>>>>>>>> site-packages are? May be, but how the pgAdmin4 runtime will know where the
>>>>>>>> Web App is installed?
>>>>>>>>
>>>>>>>> The changes that I have done to the runtime is to let it know the
>>>>>>>> path of the Web App which is present in
>>>>>>>> "/site-packages/pgadmin4-web-v1/pgAdmin4.py" The changes done are not to
>>>>>>>> set the PythonPath like we did for appbundle because I thought it is not
>>>>>>>> needed and it will automatically load the modules from the site-packages,
>>>>>>>> but it is to set the ApplicationPath.
>>>>>>>>
>>>>>>>> I missed something? or misunderstood something?
>>>>>>>>
>>>>>>>> On Fri, Jun 3, 2016 at 7:39 PM, Dave Page <dpage(at)pgadmin(dot)org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Well, I have to wonder why we need the changes to the runtime?
>>>>>>>>> We're linking the runtime with the same build of Python that's already on
>>>>>>>>> the system - doesn't it know where it's site-packages are already? I could
>>>>>>>>> see us needing this is we were using a distro-independent build of Python
>>>>>>>>> and wanted to find the OS site-packages location, but we're not.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jun 3, 2016 at 10:15 AM, Sandeep Thakkar <
>>>>>>>>> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Dave,
>>>>>>>>>>
>>>>>>>>>> how about changes in the pgadmin4 source code for conf.py and
>>>>>>>>>> Server.cpp? Looks okay?
>>>>>>>>>>
>>>>>>>>>> On Fri, Jun 3, 2016 at 2:41 PM, Sandeep Thakkar <
>>>>>>>>>> sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks Dave.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage(at)pgadmin(dot)org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
>>>>>>>>>>>> <sandeep(dot)thakkar(at)enterprisedb(dot)com> wrote:
>>>>>>>>>>>> > Hi Devrim, Hi Dave,
>>>>>>>>>>>> >
>>>>>>>>>>>> > I have updated the patch. The earlier patch may fail because
>>>>>>>>>>>> of app bundle
>>>>>>>>>>>> > commit in git.
>>>>>>>>>>>> >
>>>>>>>>>>>> > For testing, you may define the source tarball location as :
>>>>>>>>>>>> > Source0:
>>>>>>>>>>>> >
>>>>>>>>>>>> http://bugatti.pn.in.enterprisedb.com/temp/pgadmin4/%{name}-v%{version}.tar.gz
>>>>>>>>>>>> >
>>>>>>>>>>>> > Known issue that I'm still working on:
>>>>>>>>>>>> > 1. web rpm has a dependency on doc. But, even if I install
>>>>>>>>>>>> doc, the web
>>>>>>>>>>>> > still complains. Here is the scenario:
>>>>>>>>>>>> > [root(at)localhost tmp]# rpm -ivh
>>>>>>>>>>>> > dist/noarch/pgadmin4-web-1.0_dev-1.rhel7.noarch.rpm
>>>>>>>>>>>> > error: Failed dependencies:
>>>>>>>>>>>> > pgadmin4-doc = 1.0_dev is needed by
>>>>>>>>>>>> pgadmin4-web-1.0_dev-1.rhel7.noarch
>>>>>>>>>>>> > ... ( trimmed the python dependencies list here...)
>>>>>>>>>>>> >
>>>>>>>>>>>> > [root(at)localhost tmp]# rpm -ivh
>>>>>>>>>>>> > dist/noarch/pgadmin4-docs-1.0_dev-1.rhel7.noarch.rpm
>>>>>>>>>>>> > Preparing...
>>>>>>>>>>>> #################################
>>>>>>>>>>>> > [100%]
>>>>>>>>>>>> > Updating / installing...
>>>>>>>>>>>> > 1:pgadmin4-docs-1.0_dev-1.rhel7
>>>>>>>>>>>> #################################
>>>>>>>>>>>> > [100%]
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > [root(at)localhost tmp]# yum list | grep pgadmin4-docs
>>>>>>>>>>>> > pgadmin4-docs.noarch 1.0_dev-1.rhel7
>>>>>>>>>>>> > installed
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > [root(at)localhost tmp]# rpm -ivh
>>>>>>>>>>>> > dist/noarch/pgadmin4-web-1.0_dev-1.rhel7.noarch.rpm
>>>>>>>>>>>> > error: Failed dependencies:
>>>>>>>>>>>> > pgadmin4-doc = 1.0_dev is needed by
>>>>>>>>>>>> pgadmin4-web-1.0_dev-1.rhel7.noarch
>>>>>>>>>>>>
>>>>>>>>>>>> You have a typo - the Requires line is for pgadmin4-doc, but
>>>>>>>>>>>> the RPM
>>>>>>>>>>>> is pgadmin4-docs.
>>>>>>>>>>>>
>>>>>>>>>>>> Oh, right.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Other review comments:
>>>>>>>>>>>>
>>>>>>>>>>>> - We have multiple identical pgadmin4.spec.in's in the patch.
>>>>>>>>>>>> We need
>>>>>>>>>>>> to get that down to a single file.
>>>>>>>>>>>>
>>>>>>>>>>>> - In fact, why do we need a directory for each distro at all?
>>>>>>>>>>>> As far
>>>>>>>>>>>> as I can see, the only difference is the $DIST definition,
>>>>>>>>>>>> which is
>>>>>>>>>>>> surely something we can get programmatically very easily. It
>>>>>>>>>>>> seems to
>>>>>>>>>>>> me we could reduce this all to 3 files - Makefile, README and
>>>>>>>>>>>> pgadmin4.spec.in
>>>>>>>>>>>>
>>>>>>>>>>>> Agree. I copied the structure from somewhere thinking this is
>>>>>>>>>>> good to have more OS specific changes.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> - make rpm has a dependency on make prep. This has 2 issues as
>>>>>>>>>>>> far as I can see:
>>>>>>>>>>>>
>>>>>>>>>>>> - It does a git pull, which is bad. If I'm making an RPM from
>>>>>>>>>>>> within
>>>>>>>>>>>> the source tree, I want it for the current source. The git pull
>>>>>>>>>>>> only
>>>>>>>>>>>> makes sense for external builds, i.e. in a much larger
>>>>>>>>>>>> automated build
>>>>>>>>>>>> system.
>>>>>>>>>>>>
>>>>>>>>>>>> - It goes and grabs the source code and patches from the FTP
>>>>>>>>>>>> site.
>>>>>>>>>>>> Again, this is not what I want for an "in-tree" build. I want
>>>>>>>>>>>> to use
>>>>>>>>>>>> the source code as I have it now.
>>>>>>>>>>>>
>>>>>>>>>>>> Okay. got it. Will remove downloading the tarballs and build
>>>>>>>>>>> the cloned source.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Dave Page
>>>>>>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>>>>>>> Twitter: @pgsnake
>>>>>>>>>>>>
>>>>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sandeep Thakkar
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sandeep Thakkar
>>>>>>>>>> Lead Software Engineer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Phone: +91.20.30589505
>>>>>>>>>>
>>>>>>>>>> Website: www.enterprisedb.com
>>>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>>>
>>>>>>>>>> This e-mail message (and any attachment) is intended for the use
>>>>>>>>>> of the individual or entity to whom it is addressed. This message contains
>>>>>>>>>> information from EnterpriseDB Corporation that may be privileged,
>>>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>>>> and delete this message.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Dave Page
>>>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>>>> Twitter: @pgsnake
>>>>>>>>>
>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sandeep Thakkar
>>>>>>>> Lead Software Engineer
>>>>>>>>
>>>>>>>>
>>>>>>>> Phone: +91.20.30589505
>>>>>>>>
>>>>>>>> Website: www.enterprisedb.com
>>>>>>>> EnterpriseDB Blog: http://blogs.enterprisedb.com/
>>>>>>>> Follow us on Twitter: http://www.twitter.com/enterprisedb
>>>>>>>>
>>>>>>>> This e-mail message (and any attachment) is intended for the use of
>>>>>>>> the individual or entity to whom it is addressed. This message contains
>>>>>>>> information from EnterpriseDB Corporation that may be privileged,
>>>>>>>> confidential, or exempt from disclosure under applicable law. If you are
>>>>>>>> not the intended recipient or authorized to receive this for the intended
>>>>>>>> recipient, any use, dissemination, distribution, retention, archiving, or
>>>>>>>> copying of this communication is strictly prohibited. If you have received
>>>>>>>> this e-mail in error, please notify the sender immediately by reply e-mail
>>>>>>>> and delete this message.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Dave Page
>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>> Twitter: @pgsnake
>>>>>>>
>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sandeep Thakkar
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sandeep Thakkar
>>>>
>>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>
>
> --
> Sandeep Thakkar
>
>

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

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