Hi Jelle,
I tried to import jquery with the last version of your code
This is the resulting expression (they are a lot, this is just one)
(define-public node-jquery
(package
(name "node-jquery")
(version "3.1.0")
(source
(origin
(method url-fetch)
(uri "
https
Ludovic Courtès writes:
> I haven’t looked at the code but, as discussed at the GHM, I think that
> importing CoffeeScript and especially finding the right path in this
> maze of dependencies and versions to bootstrap it is an achievement.
>
> It provides a concrete illustration of how hard it is
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 that encourage using pre-built binaries.
> As a first attempt, I tried to recur
Jelle Licht writes:
Hi Jelle!
Here's a new patch replacing the previous one, summary
* add --binary option to importer, sets (arguments (#:binary? #t))
* use `npm build' for non-binary packages as fallback (WAS: skip)
* use `npm install -g' for non-binary packages; fixes e.g. loadash
Thompson, David writes:
> On Fri, Sep 2, 2016 at 10:24 AM, Jan Nieuwenhuizen wrote:
>
>> Also, I found that you prefer going through the repository/github
>> instead of using the dist tarball. Why is that?
>
> The tarballs distributed by NPM are considered binaries, not source.
Ah I see. In so
Hi Jan,
Thanks for your interest and work. I am currently quite occupied with
getting ready
for my next year of studies, so I will only shortly address your points;
The short of it is that the dist tarball does not always contain the actual
source code.
Examples of this include generated code, mi
On Fri, Sep 2, 2016 at 10:24 AM, Jan Nieuwenhuizen wrote:
> Also, I found that you prefer going through the repository/github
> instead of using the dist tarball. Why is that?
The tarballs distributed by NPM are considered binaries, not source.
- Dave
Jelle Licht writes:
Hi Jelle!
> - The ability to parse npm version data
> - An npm backend for ~guix import~
> - Npm modules in guix
> - An actual build system for npm packages
That's amazing. I played with it today and noticed that it always
downloads devDependencies. Why is that...I disabled
Hi, Jelle!
Jelle Licht skribis:
> To start of with something that did not work out as well as I had hoped,
> getting
> a popular build system (e.g. Gulp, Grunt, Broccoli and others) packaged. As
> mentioned in my earlier mails, the list of transitive dependencies of any of
> these suffer from at
Hi
Ricardo Wurmus writes:
> Hi
>
>> I also took both Ludovic', as well as Catonano's detailed feedback on the
>> initial draft of the recursive importer into account when rewriting it. It
>> should now only visit each node in the dependency graph once, and be a
>> whole lot
>> more efficient as
Hi
> I also took both Ludovic', as well as Catonano's detailed feedback on the
> initial draft of the recursive importer into account when rewriting it. It
> should now only visit each node in the dependency graph once, and be a
> whole lot
> more efficient as well. It is still based on the multi
Hello Guix,
In the last hours of GSoC, the time has come to report on my progress,
challenges and ideas regarding my project. To reiterate, the goals of this
project:
- The ability to parse npm version data
- An npm backend for ~guix import~
- Npm modules in guix
- An actual build system for
12 matches
Mail list logo
