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 <dp...@pgadmin.org> wrote: > Hi > > On Mon, Feb 13, 2017 at 10:47 PM, Sarah McAlear <smcal...@pivotal.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-hackers >
