On Fri, Sep 09, 2016 at 10:45:43AM +0200, Ludovic Courtès wrote:
> Yes, that’s a serious concern. Maybe all we can reasonably hope to
> achieve is to provide a core subset of the free NPM packages in Guix
> proper, built from source.
>
> People may still end up using automatically-generated, un
Hi Mike,
Mike Gerwitz skribis:
> Now how the hell is this enforced with thousands of dependencies that
> have not undergone any review, within a community that really couldn't
> care less? Even something as simple as the license: package.json has no
> legal force; it's _metadata_.
>
> I feel li
On Thu, Sep 08, 2016 at 21:54:36 +0200, Jan Nieuwenhuizen wrote:
> The question I'm trying to answer is: how does `a user' who builds a
> package from the repository install the needed dependencies.
Sorry, I misinterpreted.
`npm install ' will by default install all devDependencies; the
`--produc
Mike Gerwitz writes:
> On Thu, Sep 08, 2016 at 10:45:57 +0200, Jan Nieuwenhuizen wrote:
>> If a user builds an npm package from its source repository, I assume
>> that they install the devDependencies needed for that using npm?
>
> Unfortunately that depends on the project. Some projects use
> de
On Thu, Sep 08, 2016 at 10:45:57 +0200, Jan Nieuwenhuizen wrote:
> If a user builds an npm package from its source repository, I assume
> that they install the devDependencies needed for that using npm?
Unfortunately that depends on the project. Some projects use
devDependencies only for things l
Mike Gerwitz writes:
> If a user is able to build from source
That's a question that I like to explore.
If a user builds an npm package from its source repository, I assume
that they install the devDependencies needed for that using npm?
The transitive closure of installing all devDependencies
Just a quick note from me;
AFAIK, the http module is a built-in of node, so you can probably save
yourselves the efforts of packaging it ;-).
Furthermore, lots of development dependencies are not strictly
necessary; e.g. a minifier/uglifier is not required for most
functionality of a package, an
On Wed, Sep 07, 2016 at 07:51:46PM +0200, Jan Nieuwenhuizen wrote:
> Ludovic Courtès writes:
>
> >> Still, I think Guix would benefit from a somewhat more relaxed stance
> >> in this.
> >
> > It’s part of Guix’s mission to build from source whenever that is
> > possible, which is the case here, AI
On Tue, Sep 06, 2016 at 18:50:48 +0200, Pjotr Prins wrote:
> On Tue, Sep 06, 2016 at 11:48:04AM -0400, Thompson, David wrote:
>> This violates a core principle of Guix: reproducible builds. I don't
>> support patches that encourage using pre-built binaries.
>
> In principle I agree. We want to be
Ludovic Courtès writes:
>> Still, I think Guix would benefit from a somewhat more relaxed stance
>> in this.
>
> It’s part of Guix’s mission to build from source whenever that is
> possible, which is the case here, AIUI.
Yes, I thought so too...I shared my findings to get more viewpoints on
this
Howdy,
Pjotr Prins skribis:
> On Tue, Sep 06, 2016 at 11:48:04AM -0400, Thompson, David wrote:
>> On Sun, Sep 4, 2016 at 10:11 AM, Jan Nieuwenhuizen wrote:
>>
>> >* add --binary option to importer, sets (arguments (#:binary? #t))
>>
>> This violates a core principle of Guix: reproducible
On Tue, Sep 06, 2016 at 11:48:04AM -0400, Thompson, David wrote:
> On Sun, Sep 4, 2016 at 10:11 AM, Jan Nieuwenhuizen wrote:
>
> >* add --binary option to importer, sets (arguments (#:binary? #t))
>
> This violates a core principle of Guix: reproducible builds. I don't
> support patches tha
12 matches
Mail list logo