Re: developing javascript with guix

[Luis Felipe]

Hello,


On Wednesday, July 27th, 2022 at 23:15, Ryan Prior <rprior@protonmail.com> 
wrote:

> 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 agree. 


Using the original design of Guix website, this information could be accessible 
from "Home page → Guix in Your Field → Software developement". Clicking on that 
button would take the user to a Software Development page, which would link to 
language specific information to integrate Guix in one's workflow. So there 
would be URLs like these:

https://guix.gnu.org/en/software-development/
https://guix.gnu.org/en/software-development/javascript/
https://guix.gnu.org/en/software-development/python/
https://guix.gnu.org/en/software-development/ruby/

The "Guix in Your Field" idea seems kind of forsaken, but I think it is quite 
important.


> 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.

I'd say, pick one language and start :)

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature