Re: [pgadmin-hackers] SlickGrid - Mailing list pgadmin-hackers

From Dave Page
Subject Re: [pgadmin-hackers] SlickGrid
Date
Msg-id CA+OCxozY-GjmSU5ctM0=icVq-n6E1DggcMc4NmUr7xB4bhpLuw@mail.gmail.com
Whole thread Raw
In response to [pgadmin-hackers] SlickGrid  (Sarah McAlear <smcalear@pivotal.io>)
Responses Re: [pgadmin-hackers] SlickGrid
List pgadmin-hackers
Hi

On Wed, Feb 15, 2017 at 3:05 PM, Sarah McAlear <smcalear@pivotal.io> wrote:
> Hi Dave
>
>>
>> The difference with PIP is that a) the packages can be specific to the
>> version of Python in use, and b) there are multiple other packaged
>> sources of many of the packages available, e.g. RPMs.
>
>
> There are multiple packaged sources of many js packages available as well.
> For example, bootstrap can be installed by npm, bower, or composer.
>
>> 1) What would the workflow look like for developers, packagers and
>> from-source users?
>
>
> - Developers would add any new js dependencies to a package.json, which
> would be checked into the pgadmin4 repo
> - For setup and packagers, the workflow would introduce the step npm
> install, which would pick up js dependencies from the package.json
> - For development or installation, the package manager would need to be
> installed on the machine

Additional complication to an already non-trivial build environment.

>> 2) What benefit would it give us?
>
>
> - clearer separation of vendor from application code. To fresh eyes, it is
> not immediately apparent what js is actual pgadmin code
> - transitive dependencies don't need to be manually managed
> - keeping up to date with bugfixes, etc. in our dependencies. One way of
> addressing the compatibility concern (besides running tests) is to
> major-version-lock the dependencies (e.g. "~1.2.0" would allow 1.2.x but not
> 1.3)
> - protects the codebase from changes to vendorized code

The problem is that we won't get to that point, as a number of our
dependencies are not available in npm from I can see, so we'll have a
mix n match of in-tree components and out of tree ones, which arguably
means that at least the first couple of points you give above become
even more complex.

Another couple of random questions:

- How would our modularisation be affected? At present, if we only
need a JS module in a particular module, then it's confined to there.
e.g. the grant wizard may include a JS library in the python module
that implements it.

- One of the TODO items on my list is to ensure we only keep the
source to each JS module in the GIT repo, and that as part of the
various build processes we create a minimised version of every JS and
CSS we have, with pgAdmin picking the one to used based on whether or
not debugging is enabled. Could we still do something like this with
npm, or are we at the mercy of each upstream project and whether or
not they wish to provide minimised files (and with what filenames)?

Don't get me wrong, I'm not against improving things here - but I'm
as-yet unconvinced that this proposal adds more than it would
inconvenience.

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

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


pgadmin-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: [pgadmin-hackers] [pgAdmin4][Patch]: RM 2089 - PARALLEL SAFEsupport for functions missing
Next
From: Dave Page
Date:
Subject: [pgadmin-hackers] pgAdmin 4 commit: Correct node labels in Preferences for EDBfunctions