Re: developing javascript with guix

[Ryan Prior]

On Wednesday, July 27th, 2022 at 10:25 PM, jgart <jgart@dismail.de> wrote:


>
>
> On Wed, 27 Jul 2022 11:33:43 +0200 Maxime Devos maximedevos@telenet.be wrote:
>
>
> Hi Maxime,
>
> Hope all is well.
>
> > Let's try not doing anything special:
>
>
> Thanks for the repl example and for trying out a Guix developer js
> workflow for me. Do you happen to know if the same approach works
> for erlang?
>
> I think we should have language developer documentation for
> general orientation of new Guix users. Ryan Prior, another Guix
> contributor/developer has mentioned this idea to me before.

Hey Guix! Since I'm mentioned here, I'll throw in a couple ideas.

First, an issue about unexpected behavior. I tried running this:

guix shell node-sqlite3 -- node <<<"console.log(require('sqlite3'))"

It gave me an error saying it couldn't find the module sqlite3. Turns out it's 
because I was using node from my base profile and not from the shell. Running 
the shell with `--pure` makes it give a more helpful error, "node: command not 
found."

Why isn't node a dependency for node-mersenne though? Is there really a use 
case for shipping the source code of a JavaScript library without the 
interpreter? At a minimum, can we make `guix shell` warn on stderr if you 
create a shell with one or more libraries but no interpreter?

Second, a point about documentation. It's pretty obvious to most of us how to 
use JavaScript libraries (or Python, etc) with Guix, modulo small issues like 
the above. But Guix has two weaknesses here in comparison to other 
language-specific package managers:

## Explanation in context

The language-specific package managers generally don't take for granted that 
people know anything about the language, because they're designed to be 
accessible to learners of the language. For example, PyPI's explanation for pip 
starts with the basic "can you even run Python?" and goes through a bunch of 
Python-specific package workflows: 
https://packaging.python.org/en/latest/tutorials/installing-packages/

We could write a guide like that with information and example commands specific 
to Python packaging, and another for JavaScript, etc. These provide explanation 
in context so beginners and people who are confused for whatever reason can see 
concrete examples of what you're supposed to do.

## Specificity implies belonging

A Python-specific package manager is full of references to Python, libraries 
for Python, tools for Python programmers. If you're doing Python, the PyPI 
shouts loud and clear: "you are in the right place!"

Likewise for JavaScript and npm, Ruby and gems, etc. Landing on the pages for 
any of those package managers confirms that you are in a place where you will 
find information and tools that will help you with your language and package 
commons of choice. When you do a search for "MySQL" on PyPI, you only see 
Python MySQL packages, not random other stuff. The interface and search quickly 
confirm that you have found the right place with the right stuff for you.

Meanwhile, in the Guix docs, everything is abstract. We don't name any specific 
library commons or restrict package search to any specific namespace, we don't 
even have tags or categories for them. There is no link to Guix documentation I 
can give to a Python hacker that assures them, in the way PyPI's website does, 
that Guix has the stuff they need and they can find it and make it work. So 
Guix requires more faith and experimentation from users, which means a lot of 
people will just bounce off it.

I talk to somebody about once a week who says "oh I've heard of Guix and keep 
meaning to try it." The project has built up a lot of indistinct good faith 
that it has yet to make good on, so to speak. I think we can make a much better 
experience for users from the various language library commons if we build 
language-specific landing pages with instructions, documentation, and package 
search that affirm they are in the right place and will find the right stuff, 
and don't make much assumption that the person knows what they are doing.

I'll pitch in on this effort! I have experience with Ruby, JavaScript and 
Python packaging and tooling and am to help build out all those areas. Our 
emerging teams can help lend some structure to this effort too, I imagine.

Cheers,
Ryan