Обсуждение: Patch for pgAdmin4 RPM package

Поиск
Список
Период
Сортировка

Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
Hi Team, Dave,

Attached herewith are two patches. 

pgadmin4-rpm.patch - This is the main patch that includes scripts, makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24. 

It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm depends on web and the web rpm depends on the python packages. I have commented the list of packages which are not available on some systems so that Devrim can build them.

The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and pgadmin4-web is the site-packages/pgadmin4-web

pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As said pgadmin4-web and runtime installation directories are different and that means web does not exists in parallel to runtime like in sources. 

I observed that the location of application settings was not defined in Server.cpp. As per QSettings doc, the default location on Unix is the $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user that runs the application. So, I thought why not to define the application settings in application directory itself. RPM then knows where to define the ApplicationPath. I tested it and it worked fine with me. I haven't done this change for platform dependent. 

Another change that I did in this file is that, I observed that canonicalPath() was not giving the absolute path (by removing the sym link and the redundant ".." as per doc). Hence, I used absolutePath() for the paths[i] that are relative (../web, etc) and not for the already absolute path (ex. ApplicationPath like /usr/lib/python2.7/site-packages/pgadmin4-web). 

Well, I'm not a developer and the patch is just an attempt to resolve the issue related to packaging. Please feel free to change it as required for better.  

Thanks.

-- 

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.
Вложения

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
Hi

Initial eyeball review comments below...

On Fri, Apr 22, 2016 at 11:57 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:
Hi Team, Dave,

Attached herewith are two patches. 

pgadmin4-rpm.patch - This is the main patch that includes scripts, makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24. 


Can we keep the directory names in lower case?
 

It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm depends on web and the web rpm depends on the python packages. I have commented the list of packages which are not available on some systems so that Devrim can build them.

The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and pgadmin4-web is the site-packages/pgadmin4-web

Shouldn't the -web package also have the major.minor version number in the path, to allow side-by-side installation? 

pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As said pgadmin4-web and runtime installation directories are different and that means web does not exists in parallel to runtime like in sources. 

I observed that the location of application settings was not defined in Server.cpp. As per QSettings doc, the default location on Unix is the $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user that runs the application. So, I thought why not to define the application settings in application directory itself. RPM then knows where to define the ApplicationPath. I tested it and it worked fine with me. I haven't done this change for platform dependent. 

Doesn't that prevent non-root users from changing the settings? Or (if you widen the permissions on the ini file), allow one user to mis-configure the app for others? I think what is needed here is a search path change, much like you added for the Mac app bundle. 

Other thoughts:

- Please rename the README to README.txt

- The code to build the RPMs should be entirely confined to pkg/rpm. A Makefile target should be added to /Makefile to build/clean the targets (this mistake was made with the Mac package too, but was one of the original requirements).

Please resolve these issues and I'll take another look.

Thanks.

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

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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:


On Mon, May 9, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

Initial eyeball review comments below...

On Fri, Apr 22, 2016 at 11:57 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:
Hi Team, Dave,

Attached herewith are two patches. 

pgadmin4-rpm.patch - This is the main patch that includes scripts, makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24. 


Can we keep the directory names in lower case?
 
Sure. Will do that. 

It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm depends on web and the web rpm depends on the python packages. I have commented the list of packages which are not available on some systems so that Devrim can build them.

The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and pgadmin4-web is the site-packages/pgadmin4-web

Shouldn't the -web package also have the major.minor version number in the path, to allow side-by-side installation?
Right. Now that we don't have major/minor, so, will it be /usr/pgadmin4-v1 and pgadmin4-web-v1 ? Or? 
 

pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As said pgadmin4-web and runtime installation directories are different and that means web does not exists in parallel to runtime like in sources. 

I observed that the location of application settings was not defined in Server.cpp. As per QSettings doc, the default location on Unix is the $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user that runs the application. So, I thought why not to define the application settings in application directory itself. RPM then knows where to define the ApplicationPath. I tested it and it worked fine with me. I haven't done this change for platform dependent. 

Doesn't that prevent non-root users from changing the settings? Or (if you widen the permissions on the ini file), allow one user to mis-configure the app for others? I think what is needed here is a search path change, much like you added for the Mac app bundle. 

Right. Will use python command to find the site-packages path and then concatenate pgadmin4-web directory name. 
Other thoughts:

- Please rename the README to README.txt

- The code to build the RPMs should be entirely confined to pkg/rpm. A Makefile target should be added to /Makefile to build/clean the targets (this mistake was made with the Mac package too, but was one of the original requirements).

Please resolve these issues and I'll take another look.

Sure. Will share it with you soon.
 
Thanks.

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

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



--
Sandeep Thakkar

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
[Adding Devrim]

On Fri, May 27, 2016 at 1:55 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
>
>
> On Mon, May 9, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> Initial eyeball review comments below...
>>
>> On Fri, Apr 22, 2016 at 11:57 AM, Sandeep Thakkar
>> <sandeep.thakkar@enterprisedb.com> wrote:
>>>
>>> Hi Team, Dave,
>>>
>>> Attached herewith are two patches.
>>>
>>> pgadmin4-rpm.patch - This is the main patch that includes scripts,
>>> makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24.
>>
>>
>> Can we keep the directory names in lower case?
>>
>
> Sure. Will do that.
>>>
>>> It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm
>>> depends on web and the web rpm depends on the python packages. I have
>>> commented the list of packages which are not available on some systems so
>>> that Devrim can build them.
>>>
>>> The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and
>>> pgadmin4-web is the site-packages/pgadmin4-web
>>
>> Shouldn't the -web package also have the major.minor version number in the
>> path, to allow side-by-side installation?
>
> Right. Now that we don't have major/minor, so, will it be /usr/pgadmin4-v1
> and pgadmin4-web-v1 ? Or?

I think that's fine.

>>
>>
>>>
>>> pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As
>>> said pgadmin4-web and runtime installation directories are different and
>>> that means web does not exists in parallel to runtime like in sources.
>>>
>>> I observed that the location of application settings was not defined in
>>> Server.cpp. As per QSettings doc, the default location on Unix is the
>>> $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user
>>> that runs the application. So, I thought why not to define the application
>>> settings in application directory itself. RPM then knows where to define the
>>> ApplicationPath. I tested it and it worked fine with me. I haven't done this
>>> change for platform dependent.
>>
>> Doesn't that prevent non-root users from changing the settings? Or (if you
>> widen the permissions on the ini file), allow one user to mis-configure the
>> app for others? I think what is needed here is a search path change, much
>> like you added for the Mac app bundle.
>>
> Right. Will use python command to find the site-packages path and then
> concatenate pgadmin4-web directory name.

OK.

>> Other thoughts:
>>
>> - Please rename the README to README.txt
>>
>> - The code to build the RPMs should be entirely confined to pkg/rpm. A
>> Makefile target should be added to /Makefile to build/clean the targets
>> (this mistake was made with the Mac package too, but was one of the original
>> requirements).
>>
>> Please resolve these issues and I'll take another look.
>>
> Sure. Will share it with you soon.

-> Devrim please :-)

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

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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
Hi Devrim,

I have attached the patch for review. Please note that right now I have commented the python dependencies (in Requires) which you are building. Please review and let me know if specfile or anything else needs some changes. Once the rpms are built, please let me know how to install them so that I will enable those dependencies and do the testing.

Hi Dave,

The rpm will be built in $SRC/rpm-build. Inside this, we have the directories for sources (where tarball will be downloaded - for testing, I have mentioned the path of Bugatti :) ), build, etc. 

The html docs was not building and I had to make changes in docs/conf.py and install sphinx_rtd_theme. I have added this dependency and the Sphinx in the specfile. May be should add it in the requirements also? I tested this change on OS X and make docs is building fine.

Since web package is installed in the default python site-packages as pgadmin4-web-v1 (for release "1"), with the help of Neel, I could made changes in Server.cpp to find that location. But, couldn't understand how to get the app release info, hence right now hard-coded the string as 'pgadmin4-web-v1".

Note: In the patch, the Makefile and .gitignore also contains the mac related changes. This is just to see how they will look finally after mac and rpm changes are done. I will remove them from the rpm patch once the mac appbundle patch is committed.

Questions:
1. Should we add 'docs' dependency target for 'rpm' like we did for appbundle?
2. Should web rpm require doc rpm? I guess so, otherwise online help won't work. Right?

On Fri, May 27, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
[Adding Devrim]

On Fri, May 27, 2016 at 1:55 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
>
>
> On Mon, May 9, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> Initial eyeball review comments below...
>>
>> On Fri, Apr 22, 2016 at 11:57 AM, Sandeep Thakkar
>> <sandeep.thakkar@enterprisedb.com> wrote:
>>>
>>> Hi Team, Dave,
>>>
>>> Attached herewith are two patches.
>>>
>>> pgadmin4-rpm.patch - This is the main patch that includes scripts,
>>> makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24.
>>
>>
>> Can we keep the directory names in lower case?
>>
>
> Sure. Will do that.
>>>
>>> It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm
>>> depends on web and the web rpm depends on the python packages. I have
>>> commented the list of packages which are not available on some systems so
>>> that Devrim can build them.
>>>
>>> The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and
>>> pgadmin4-web is the site-packages/pgadmin4-web
>>
>> Shouldn't the -web package also have the major.minor version number in the
>> path, to allow side-by-side installation?
>
> Right. Now that we don't have major/minor, so, will it be /usr/pgadmin4-v1
> and pgadmin4-web-v1 ? Or?

I think that's fine.

>>
>>
>>>
>>> pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As
>>> said pgadmin4-web and runtime installation directories are different and
>>> that means web does not exists in parallel to runtime like in sources.
>>>
>>> I observed that the location of application settings was not defined in
>>> Server.cpp. As per QSettings doc, the default location on Unix is the
>>> $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user
>>> that runs the application. So, I thought why not to define the application
>>> settings in application directory itself. RPM then knows where to define the
>>> ApplicationPath. I tested it and it worked fine with me. I haven't done this
>>> change for platform dependent.
>>
>> Doesn't that prevent non-root users from changing the settings? Or (if you
>> widen the permissions on the ini file), allow one user to mis-configure the
>> app for others? I think what is needed here is a search path change, much
>> like you added for the Mac app bundle.
>>
> Right. Will use python command to find the site-packages path and then
> concatenate pgadmin4-web directory name.

OK.

>> Other thoughts:
>>
>> - Please rename the README to README.txt
>>
>> - The code to build the RPMs should be entirely confined to pkg/rpm. A
>> Makefile target should be added to /Makefile to build/clean the targets
>> (this mistake was made with the Mac package too, but was one of the original
>> requirements).
>>
>> Please resolve these issues and I'll take another look.
>>
> Sure. Will share it with you soon.

-> Devrim please :-)

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

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



--
Sandeep Thakkar

Вложения

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
Hi

Few changes in the updated patch:
- added the missing modules in the specfile. The unavailable modules are still commented. 
- added changelog in specfile
- added dependency of pgadmin4-doc on pgadmin4-web

On Wed, Jun 1, 2016 at 2:57 PM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:
Hi Devrim,

I have attached the patch for review. Please note that right now I have commented the python dependencies (in Requires) which you are building. Please review and let me know if specfile or anything else needs some changes. Once the rpms are built, please let me know how to install them so that I will enable those dependencies and do the testing.

Hi Dave,

The rpm will be built in $SRC/rpm-build. Inside this, we have the directories for sources (where tarball will be downloaded - for testing, I have mentioned the path of Bugatti :) ), build, etc. 

The html docs was not building and I had to make changes in docs/conf.py and install sphinx_rtd_theme. I have added this dependency and the Sphinx in the specfile. May be should add it in the requirements also? I tested this change on OS X and make docs is building fine.

Since web package is installed in the default python site-packages as pgadmin4-web-v1 (for release "1"), with the help of Neel, I could made changes in Server.cpp to find that location. But, couldn't understand how to get the app release info, hence right now hard-coded the string as 'pgadmin4-web-v1".

Note: In the patch, the Makefile and .gitignore also contains the mac related changes. This is just to see how they will look finally after mac and rpm changes are done. I will remove them from the rpm patch once the mac appbundle patch is committed.

Questions:
1. Should we add 'docs' dependency target for 'rpm' like we did for appbundle?
2. Should web rpm require doc rpm? I guess so, otherwise online help won't work. Right?

On Fri, May 27, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
[Adding Devrim]

On Fri, May 27, 2016 at 1:55 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
>
>
> On Mon, May 9, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> Initial eyeball review comments below...
>>
>> On Fri, Apr 22, 2016 at 11:57 AM, Sandeep Thakkar
>> <sandeep.thakkar@enterprisedb.com> wrote:
>>>
>>> Hi Team, Dave,
>>>
>>> Attached herewith are two patches.
>>>
>>> pgadmin4-rpm.patch - This is the main patch that includes scripts,
>>> makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24.
>>
>>
>> Can we keep the directory names in lower case?
>>
>
> Sure. Will do that.
>>>
>>> It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm
>>> depends on web and the web rpm depends on the python packages. I have
>>> commented the list of packages which are not available on some systems so
>>> that Devrim can build them.
>>>
>>> The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and
>>> pgadmin4-web is the site-packages/pgadmin4-web
>>
>> Shouldn't the -web package also have the major.minor version number in the
>> path, to allow side-by-side installation?
>
> Right. Now that we don't have major/minor, so, will it be /usr/pgadmin4-v1
> and pgadmin4-web-v1 ? Or?

I think that's fine.

>>
>>
>>>
>>> pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As
>>> said pgadmin4-web and runtime installation directories are different and
>>> that means web does not exists in parallel to runtime like in sources.
>>>
>>> I observed that the location of application settings was not defined in
>>> Server.cpp. As per QSettings doc, the default location on Unix is the
>>> $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user
>>> that runs the application. So, I thought why not to define the application
>>> settings in application directory itself. RPM then knows where to define the
>>> ApplicationPath. I tested it and it worked fine with me. I haven't done this
>>> change for platform dependent.
>>
>> Doesn't that prevent non-root users from changing the settings? Or (if you
>> widen the permissions on the ini file), allow one user to mis-configure the
>> app for others? I think what is needed here is a search path change, much
>> like you added for the Mac app bundle.
>>
> Right. Will use python command to find the site-packages path and then
> concatenate pgadmin4-web directory name.

OK.

>> Other thoughts:
>>
>> - Please rename the README to README.txt
>>
>> - The code to build the RPMs should be entirely confined to pkg/rpm. A
>> Makefile target should be added to /Makefile to build/clean the targets
>> (this mistake was made with the Mac package too, but was one of the original
>> requirements).
>>
>> Please resolve these issues and I'll take another look.
>>
> Sure. Will share it with you soon.

-> Devrim please :-)

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

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



--
Sandeep Thakkar




--
Sandeep Thakkar

Вложения

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
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 :

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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
pgadmin4-docs.noarch                    1.0_dev-1.rhel7                installed


[root@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
--

Thanks!

On Thu, Jun 2, 2016 at 6:29 PM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:
Hi

Few changes in the updated patch:
- added the missing modules in the specfile. The unavailable modules are still commented. 
- added changelog in specfile
- added dependency of pgadmin4-doc on pgadmin4-web

On Wed, Jun 1, 2016 at 2:57 PM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:
Hi Devrim,

I have attached the patch for review. Please note that right now I have commented the python dependencies (in Requires) which you are building. Please review and let me know if specfile or anything else needs some changes. Once the rpms are built, please let me know how to install them so that I will enable those dependencies and do the testing.

Hi Dave,

The rpm will be built in $SRC/rpm-build. Inside this, we have the directories for sources (where tarball will be downloaded - for testing, I have mentioned the path of Bugatti :) ), build, etc. 

The html docs was not building and I had to make changes in docs/conf.py and install sphinx_rtd_theme. I have added this dependency and the Sphinx in the specfile. May be should add it in the requirements also? I tested this change on OS X and make docs is building fine.

Since web package is installed in the default python site-packages as pgadmin4-web-v1 (for release "1"), with the help of Neel, I could made changes in Server.cpp to find that location. But, couldn't understand how to get the app release info, hence right now hard-coded the string as 'pgadmin4-web-v1".

Note: In the patch, the Makefile and .gitignore also contains the mac related changes. This is just to see how they will look finally after mac and rpm changes are done. I will remove them from the rpm patch once the mac appbundle patch is committed.

Questions:
1. Should we add 'docs' dependency target for 'rpm' like we did for appbundle?
2. Should web rpm require doc rpm? I guess so, otherwise online help won't work. Right?

On Fri, May 27, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
[Adding Devrim]

On Fri, May 27, 2016 at 1:55 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
>
>
> On Mon, May 9, 2016 at 6:35 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> Initial eyeball review comments below...
>>
>> On Fri, Apr 22, 2016 at 11:57 AM, Sandeep Thakkar
>> <sandeep.thakkar@enterprisedb.com> wrote:
>>>
>>> Hi Team, Dave,
>>>
>>> Attached herewith are two patches.
>>>
>>> pgadmin4-rpm.patch - This is the main patch that includes scripts,
>>> makefiles and spec to create RPMs for RHEL6/RHEL7/F-22/F-23/F-24.
>>
>>
>> Can we keep the directory names in lower case?
>>
>
> Sure. Will do that.
>>>
>>> It will create two RPMs i.e pgadmin4 and pgadmin4-web. The  pgadmin4 tpm
>>> depends on web and the web rpm depends on the python packages. I have
>>> commented the list of packages which are not available on some systems so
>>> that Devrim can build them.
>>>
>>> The installation path for pgadmin4 is "/usr/pgadmin4-<major>.<minor>" and
>>> pgadmin4-web is the site-packages/pgadmin4-web
>>
>> Shouldn't the -web package also have the major.minor version number in the
>> path, to allow side-by-side installation?
>
> Right. Now that we don't have major/minor, so, will it be /usr/pgadmin4-v1
> and pgadmin4-web-v1 ? Or?

I think that's fine.

>>
>>
>>>
>>> pgadmin4-server-ini.patch - This is the patch for runtime/Server.cpp. As
>>> said pgadmin4-web and runtime installation directories are different and
>>> that means web does not exists in parallel to runtime like in sources.
>>>
>>> I observed that the location of application settings was not defined in
>>> Server.cpp. As per QSettings doc, the default location on Unix is the
>>> $HOME/.config/<companyname>/<appname>.conf. Here, $HOME depends on the user
>>> that runs the application. So, I thought why not to define the application
>>> settings in application directory itself. RPM then knows where to define the
>>> ApplicationPath. I tested it and it worked fine with me. I haven't done this
>>> change for platform dependent.
>>
>> Doesn't that prevent non-root users from changing the settings? Or (if you
>> widen the permissions on the ini file), allow one user to mis-configure the
>> app for others? I think what is needed here is a search path change, much
>> like you added for the Mac app bundle.
>>
> Right. Will use python command to find the site-packages path and then
> concatenate pgadmin4-web directory name.

OK.

>> Other thoughts:
>>
>> - Please rename the README to README.txt
>>
>> - The code to build the RPMs should be entirely confined to pkg/rpm. A
>> Makefile target should be added to /Makefile to build/clean the targets
>> (this mistake was made with the Mac package too, but was one of the original
>> requirements).
>>
>> Please resolve these issues and I'll take another look.
>>
> Sure. Will share it with you soon.

-> Devrim please :-)

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

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



--
Sandeep Thakkar




--
Sandeep Thakkar




--
Sandeep Thakkar

Вложения

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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.

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

- 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.

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

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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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.

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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.

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
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.

Does anyone think we need to support side-by-side RPM/DEB installation of multiple major versions of pgAdmin? Devrim? Hamid?

The config file would be part of the web package.

On Mon, Jun 6, 2016 at 10:09 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
--Adding back Devrim :-)


On Mon, Jun 6, 2016 at 2:44 PM, Dave Page <dpage@pgadmin.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.

Does anyone think we need to support side-by-side RPM/DEB installation of multiple major versions of pgAdmin? Devrim? Hamid?

The config file would be part of the web package.

On Mon, Jun 6, 2016 at 10:09 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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
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.

Re: Patch for pgAdmin4 RPM package

От
Ashesh Vashi
Дата:
On Mon, Jun 6, 2016 at 2:44 PM, Dave Page <dpage@pgadmin.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



The config file would be part of the web package.

On Mon, Jun 6, 2016 at 10:09 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Re: Patch for pgAdmin4 RPM package

От
Sandeep Thakkar
Дата:
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.


On Mon, Jun 6, 2016 at 2:47 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
On Mon, Jun 6, 2016 at 2:44 PM, Dave Page <dpage@pgadmin.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



The config file would be part of the web package.

On Mon, Jun 6, 2016 at 10:09 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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

Вложения

Re: Patch for pgAdmin4 RPM package

От
Dave Page
Дата:
Hi

On Tue, Jun 7, 2016 at 8:02 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.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.


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

 


On Mon, Jun 6, 2016 at 2:47 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
On Mon, Jun 6, 2016 at 2:44 PM, Dave Page <dpage@pgadmin.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



The config file would be part of the web package.

On Mon, Jun 6, 2016 at 10:09 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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@pgadmin.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.thakkar@enterprisedb.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.thakkar@enterprisedb.com> wrote:
Thanks Dave. 

On Fri, Jun 3, 2016 at 2:08 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 2, 2016 at 4:23 PM, Sandeep Thakkar
<sandeep.thakkar@enterprisedb.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@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@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@localhost tmp]# yum list | grep pgadmin4-docs
> pgadmin4-docs.noarch                    1.0_dev-1.rhel7
> installed
>
>
> [root@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