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

Hi

On Wed, Feb 22, 2017 at 9:23 PM, Atira Odhner <aodhner@pivotal.io> wrote:
>> The difference with PIP is that a) the packages can be specific to the
>> version of Python in use
>
>
> The javascript is going to run in the end-user's browser regardless of what
> is installed on the machine where the app is packaged. Varying what versions
> of the libraries are in use in that way for javascript dependencies would be
> unnecessary build complication.

That's my point. We don't need or want a varying set of packages at
the javascript end.

>> 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.
>
>
> I took a quick peek at the dependencies that we are using and didn't see any
> not available in npm. Additionally, I would like to at least quarantine the
> vendorized dependencies away from the pgadmin code itself into a separate
> directory. e.g static/js/vendor/

piranha:pgadmin4 dpage$ npm search wcdocker
No matches found for "wcdocker"
piranha:pgadmin4 dpage$ npm search acitree
No matches found for "acitree"

I have no problem with moving packages into a vendor directory. Feel
free to send a patch - in fact, that would be a good time to
re-structure such that all vendor code follows it's original
structure, rather than using the strict separation of js/css that
we've (short-sightedly) moved it into. That alone would make future
upgrades much easier.

>> - 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.
>
>
> Other than changing some file paths in define/require, there's no technical
> reason that would force us to change anything about the modularity of the
> code simply by moving dependencies to npm.

So we could define dependencies on a per-module basis?

>> - 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)?
>
>
>  There are lots of tools like Grunt/Gulp babelify/browserify/uglify which
> could automate minification/non-minification(DEBUG mode) for us at build
> time. That would also allow us to minify our own code, not just our
> dependencies.

Right. What I have been playing with in the past is the idea of having
only un-minimised code in the repo, with a build step that will
minimise all JS/CSS and potentially HTML, creating versions of each
file with a name.ext.min name format, then modifying pgAdmin to look
for a .min version of each file if running in release mode.

What concerns me with using npm and trying to automate this is that
package A might install:

js/pkgA.js
js/pkgA.js.min

Package B might install:

js/pkgB.js

Package C might install:

js/pkgC.js
js/pkgC.min.js

And package D might install:

js/pkgD-1.js
js/pkgD-2.js
js/pkgD-3.js
js/pkgD.min.js

and so on.

By having the dependencies in the tree, we can fix and control those
differences, and then have a standardised, automated and global way of
minimising.

> I think moving to npm would make it easier to pull in some of that tooling,
> but of course we could just keep checking all that code into our git repo.
> Either way, moving the DEBUG configuration out of the code and into the
> build configuration would tidy up our js dependency inclusion.
>
> I'm still not sure I see the benefit of keeping the js checked into the git
> repo as compared to PIP dependencies, but we could do so if we wished.  One
> thing I've done on certain projects is check in the *built* javascript so
> that developers who are not concerned with making js changes do not have to
> set up any js tooling.

That goes against what many consider to be a basic rule of version
control - never check in compiled/built files, only the source to
build them.

>> > We agree that there might be cases where we need to vendorize assets but
>> > that shouldn't dictate our default approach to managing assets.
>> Neither should a trend towards using NPM like all the cool kids
>> (which, as relational database people, we're not) :-).
>
>
> I realize that npm is a spritely young 7 year old tool, but if we want to
> build a community of contributors, might it behoove us to consider what the
> cool kids are doing? :-p

Lol! I'm happy to consider - I just want to be sure we're making
changes for the right reasons; i.e. they will improve the
code/product, or make it easier for us to get work done. I don't want
to do things *just* because they're what the cool kids are doing :-)

> All that said, I understand the allure of not adding new tools as it is one
> more thing to worry about.
>
> Cheers,
> Tira
>
> On Wed, Feb 15, 2017 at 10:59 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> 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
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>
>



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

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