to have such tool maintained outside of Guix
>> proper.
>
> The reason I called it the “NPM Binary Importer” was to scare people
> away, because its results are rather limited. Maybe I went too far,
> though, and people are too scared! :)
>
> It’s more accurately the “Half
Hi,
On Fri, 8 Oct 2021 at 16:17, Katherine Cox-Buday
wrote:
> Maxim Cournoyer writes:
>
> > I'm not too keen on having an importer which produces packages that
> > can't be included in Guix proper -- it seems a double standard to me.
> > I'd personally prefer to have such tool maintained outside
Hi
I programmed the whole day and learned a lot. :D
On 2018-11-30 17:13, swedebugia wrote:
snip
TODO:
* make npm-recursive-import work by not fetching blacklisted packages
See the attached patches :)
* implement keyword blacklisting based on the descriptions
* match not just the whole s
On 2018-11-30 17:24, Julien Lepiller wrote:
Le 2018-11-30 17:13, swedebugia a écrit :
snip
Hi,
I never used the recursive importer, so I didn't know it wasn't very good.
I wonder if we really need to import every version of the packages. That
doesn't seem very practical. There are a few cy
Le 2018-11-30 17:13, swedebugia a écrit :
Hi :)
On 2018-11-11 16:37, Julien Lepiller wrote:
I improved a bit over jlicht's work here, but there still a few tgings
we want co work on: https://framagit.org/tyreunom/guix/tree/npm
There is an importer and a build system as well as a few packages.
Hi :)
On 2018-11-11 16:37, Julien Lepiller wrote:
I improved a bit over jlicht's work here, but there still a few tgings we want
co work on: https://framagit.org/tyreunom/guix/tree/npm
There is an importer and a build system as well as a few packages. One of tge
issue is that the importer is
On 2018-11-22 02:02, swedebugia wrote:
Hi
On 2018-11-22 00:22, swedebugia wrote:
snip
snip
While investigating the top libraries* packages with most depends in npm
I found the following:
Lib Dep DevDep RecdevDep Dependants license
underscore 0 12 2400+ 18
Hi Giovanni,
> what about reusing work already done from the Debian JavaScript
> Maintainers team [1]?
[…]
> should we ignore/deprecate npm packages with licensing issues and work
> with the ethically conscious like Debian JavaScript Maintainers?
I think this would be a good thing to try. Work
swedebugia writes:
> uglify-js is a minifier used in a lot of projects and the only one
> needed for this specific project.
>
> For packages like this we could probably patch the package to skip the
> minifying step and let the user choose which minifier (if any) to use.
>
> In this particular
Hi
I looked closer at the json output from npmregistry and found that they
host tarballs and give the url for every version in the json response.
("tarball" . "url").
All the npm packages I ever looked at (100 or so of the biggest and
dependencies of those) was hosted on Github.
I have a fe
because I made so many typing mistakes, I corrected my text and I'm posting
it again, corrected
There are 2 observations I can give
The first one is that "member" returns a boolean value (#t or #f) and your
function can return just that, you don't need the if
But even if you needed the if,
Il giorno dom 25 nov 2018 alle ore 14:21 swedebugia
ha scritto:
> Hi
>
> I am still a novice in guile so I humbly ask for help with this error
> trying to get the blacklisting to work:
>
> sdb@komputilo ~$ ~/guix-tree/pre-inst-env guix import npm leaflet
> ice-9/boot-9.scm:222:17: In procedure ma
Hello,
I had a look at that. You should not need the if there, just 'return'
the test of the if.
If has a form (if test conseqent alternate), alternate is optional and
returns the value of the
evaluated branch (consequent or alternate). This gives you a syntax
error, as the mandatory
consequent ex
Hi
I am still a novice in guile so I humbly ask for help with this error
trying to get the blacklisting to work:
sdb@komputilo ~$ ~/guix-tree/pre-inst-env guix import npm leaflet
ice-9/boot-9.scm:222:17: In procedure map1:
Syntax error:
/home/sdb/guix-tree/guix/import/npm.scm:304:2: source exp
On 2018-11-22 09:36, Julien Lepiller wrote:
Thanks! It made me wonder if we could better approximate the set of needed
dependencies by looking at package tags. I'll try to improve my script in that
spirit, and share it again here.
Sounds good.
I would like to work on implementing a way to bl
Hi
On 2018-11-20 08:50, Julien Lepiller wrote:
snip
I'll push what I have to a wip-branch latter today. The reason why I develop
out-of-tree is because I can always rebase my patches.
I don't see it in guix yet. Could you push it?
I corrected a bug in node-build-system and added node-unders
On 2018-11-22 02:02, swedebugia wrote:
Hi
On 2018-11-22 00:22, swedebugia wrote:
snip
A graph of all npm packages and top packages is also available:
https://exploring-data.com/info/npm-packages-dependencies/
This graph is in-degree and does not consider versions. It is useful
only to see t
Hi Guix!
sorry if I'm going to reinvent some wheels but I've not found previous
discussions nor documentation about what I'm writing
what about reusing work already done from the Debian JavaScript
Maintainers team [1]?
they set up some interesting policies we could adapt to Guix needs and
pusbli
Hi Guix,
sorry: reading at today messages from swdebugia and your comments below
I realize that mine was just noise from a packaging-ignorant :-S
Julien Lepiller writes:
[...]
>> https://spin.atomicobject.com/2016/12/16/reproducible-builds-npm-yarn/
>>
>> is yarn a viable solution to the NPM
Thanks! It made me wonder if we could better approximate the set of needed
dependencies by looking at package tags. I'll try to improve my script in that
spirit, and share it again here.
I think once we have a clearer view of what we want, we should focus on finding
the best way forward: what p
swedebugia writes:
> Hi
>
> On 2018-11-22 00:22, swedebugia wrote:
> snip
>
>> A graph of all npm packages and top packages is also available:
>> https://exploring-data.com/info/npm-packages-dependencies/
>
> While investigating the top libraries* packages with most depends in
> npm I found the
Hi
On 2018-11-22 00:22, swedebugia wrote:
snip
A graph of all npm packages and top packages is also available:
https://exploring-data.com/info/npm-packages-dependencies/
While investigating the top libraries* packages with most depends in npm
I found the following:
Lib Dep
On 2018-11-21 23:01, Brett Gilio wrote:
Mike Gerwitz writes:
The JavaScript community has poor licensing practices, and the culture
is somewhat hostile to the ideals of the free software movement (they
focus on permissive licensing to empower non-free software developers
using those libraries)
Mike Gerwitz writes:
> The JavaScript community has poor licensing practices, and the culture
> is somewhat hostile to the ideals of the free software movement (they
> focus on permissive licensing to empower non-free software developers
> using those libraries).
To say the least. It will take
Le 2018-11-21 17:37, Giovanni Biscuolo a écrit :
l...@gnu.org (Ludovic Courtès) writes:
[...]
Yes, this was the topic of a GSoC project by Jelle Licht (Cc’d). But
don’t hold your breath: as Chris Webber explained, the npm situation
is
very hard to address sanely:
http://dustycloud.org/bl
l...@gnu.org (Ludovic Courtès) writes:
[...]
> Yes, this was the topic of a GSoC project by Jelle Licht (Cc’d). But
> don’t hold your breath: as Chris Webber explained, the npm situation is
> very hard to address sanely:
>
> http://dustycloud.org/blog/javascript-packaging-dystopia/
(semi OT:
On 2018-11-20 23:35, Julien Lepiller wrote:
Le Tue, 20 Nov 2018 22:12:18 +0100,
swedebugia a écrit :
Hi
On 2018-11-20 20:58, swedebugia wrote:
On 2018-11-20 08:50, Julien Lepiller wrote:
snip
See this script that builds a graph of dependencies, ignoring
devDependencies (so none of the pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, Nov 20, 2018 at 22:12:18 +0100, swedebugia wrote:
> I wonder how many are free software? 90%? 50%?
>
> I hope we can automate this some way.
The JavaScript community has poor licensing practices, and the culture
is somewhat hostile to the id
Le Tue, 20 Nov 2018 22:12:18 +0100,
swedebugia a écrit :
> Hi
>
> On 2018-11-20 20:58, swedebugia wrote:
> > On 2018-11-20 08:50, Julien Lepiller wrote:
>
> snip
>
> >> See this script that builds a graph of dependencies, ignoring
> >> devDependencies (so none of the packages listed by this
Hi
On 2018-11-20 20:58, swedebugia wrote:
On 2018-11-20 08:50, Julien Lepiller wrote:
snip
See this script that builds a graph of dependencies, ignoring
devDependencies (so none of the packages listed by this script is
going to be tested): https://framagit.org/tyreunom/guix/snippets/2534
Hi :)
On 2018-11-20 08:50, Julien Lepiller wrote:
Well, minimist is not a small package. I have a small script somewhere that
browse the registry to find recursively the list of dependencies of a package.
I tried to run it on minimist and I stopped it after a few thousand different
packages w
Well, minimist is not a small package. I have a small script somewhere that
browse the registry to find recursively the list of dependencies of a package.
I tried to run it on minimist and I stopped it after a few thousand different
packages were found. That's also why we can't make a recursive
On 2018-11-11 16:37, Julien Lepiller wrote:
I improved a bit over jlicht's work here, but there still a few tgings we want
co work on: https://framagit.org/tyreunom/guix/tree/npm
There is an importer and a build system as well as a few packages. One of tge
issue is that the importer is not rec
Hello,
swedebugia skribis:
> Has anybody worked on that?
Yes, this was the topic of a GSoC project by Jelle Licht (Cc’d). But
don’t hold your breath: as Chris Webber explained, the npm situation is
very hard to address sanely:
http://dustycloud.org/blog/javascript-packaging-dystopia/
Ludo’
I improved a bit over jlicht's work here, but there still a few tgings we want
co work on: https://framagit.org/tyreunom/guix/tree/npm
There is an importer and a build system as well as a few packages. One of tge
issue is that the importer is not recursive, so it doesn't get the specified
versi
Hi
Has anybody worked on that?
--
Cheers
Swedebugia
guix
> import utils), instead of duplicating this effort in the npm importer.
That sounds like an improvement, would you like to help with that?
> How would you propose we get to reviewing your code? Would you care to
> send some patches, or should we bother you via gitlab a bit more?
Hello!
Christopher Allan Webber skribis:
> Jan Nieuwenhuizen writes:
[...]
>> We have a working importer for npm packages written by Jelle that I have
>> been using for about half a year. It can use some improvements and
>> that's why I think we should merge it.
>>
>> Have alook at my npm bra
p till now.
I like and agree with most of your changes as they make the code much more
robust in the face of inevitable failure.
Nonetheless, one could say that we should not make it too easy to
inadvertently create package specifications for 'binaries'.
One tiny improvement might be to u
Jan Nieuwenhuizen writes:
> Hi,
Hi Jan!
> We have a working importer for npm packages written by Jelle that I have
> been using for about half a year. It can use some improvements and
> that's why I think we should merge it.
>
> Have alook at my npm branch here, rebased on master
>
> https:
Hi,
We have a working importer for npm packages written by Jelle that I have
been using for about half a year. It can use some improvements and
that's why I think we should merge it.
Have alook at my npm branch here, rebased on master
https://gitlab.com/janneke/guix
I added a patch with se
41 matches
Mail list logo
