Hi
On Tue, Feb 14, 2017 at 3:45 PM, Atira Odhner <aodhner@pivotal.io> wrote:
> 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.
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.
> 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.
Neither should a trend towards using NPM like all the cool kids
(which, as relational database people, we're not) :-).
Before we go any further on this:
1) What would the workflow look like for developers, packagers and
from-source users?
2) What benefit would it give us?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company