Re: [pgadmin-hackers] SlickGrid
| От | Atira Odhner |
|---|---|
| Тема | Re: [pgadmin-hackers] SlickGrid |
| Дата | |
| Msg-id | CA+Vc24pXOamfLgRx0LqGFFAdGRqUcKshpzEe0_==-MExkWWx7g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [pgadmin-hackers] SlickGrid (Dave Page <dpage@pgadmin.org>) |
| Ответы |
Re: [pgadmin-hackers] SlickGrid
|
| Список | pgadmin-hackers |
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.
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.
- 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.
- 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.
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.
> 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
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
В списке pgadmin-hackers по дате отправления: