Re: SlickGrid

Hi Dave,

> we never rely on the availability of third party sites,
> especially not commercial ones.

npm is commercial and pip is supported by a noncommercial foundation, but
npm is still open source.

If you are concerned about relying on a 3rd party commercial site, perhaps
we could use npm to install and manage dependencies but also check them in
or set up pgadmin's own npm registry.

> More importantly, we a) want to know
> we have stable code in our tree (we don't want users running with
> random versions that we may not have tested yet)

npm allows version locking, the same way we handle our python dependencies.

and b) on very rare
> occasions we may modify our copies of the code - which is always a
> last resort that is documented, and where appropriate, with a patch
> sent upstream.

We agree that there might be cases where we need to vendorize assets but
that shouldn't dictate our default approach to managing assets.

Tira, Sarah & Geroge

On Tue, Feb 14, 2017 at 4:25 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Mon, Feb 13, 2017 at 10:47 PM, Sarah McAlear <smcalear(at)pivotal(dot)io>
> wrote:
> > Hi Hackers,
> >
> > We saw a story about transferring query results to SlickGrid on Redmine
> > (https://redmine.postgresql.org/issues/2036) We are considering more
> > selection options (in addition to by-row) within the results display,
> which
> > got us wondering about the use of SlickGrid.
> >
> > It appears that SlickGrid hasn't been maintained in roughly 3 years.
> What is
> > the plan going forward with this library? There does seem to be a fork
> > https://github.com/6pac/SlickGrid/tree/2.3.4 that is still maintained.
>
> That's the version we use.
>
> > For this and perhaps other js dependencies, would pulling it in via npm
> be
> > an option?
>
> No - we never rely on the availability of third party sites,
> especially not commercial ones. More importantly, we a) want to know
> we have stable code in our tree (we don't want users running with
> random versions that we may not have tested yet), and b) on very rare
> occasions we may modify our copies of the code - which is always a
> last resort that is documented, and where appropriate, with a patch
> sent upstream.
>
> --
> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>