developing javascript with guix

developing javascript with guix

[jgart]

Should we make a guide for developing with js and guix?

For example, how does a js developer use `guix shell` to load a js lib like
node-rimraf in a repl currently?

There's currently no doc for getting started with that iirc

Re: developing javascript with guix

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1467 bytes --]

On 27-07-2022 02:25, jgart wrote:

> Should we make a guide for developing with js and guix?
>
> For example, how does a js developer use `guix shell` to load a js lib like
> node-rimraf in a repl currently?
This one is not in Guix, so I'll replace it by node-mersenne.
> There's currently no doc for getting started with that iirc

Let's try not doing anything special:

$ guix shell node-mersenne node
$ node
 > mersenne = require('mersenne')
{
   MersenneTwister19937: [Function:think we need documentati 
MersenneTwister19937],
   rand: [Function (anonymous)],
   seed: [Function (anonymous)],
   seed_array: [Function (anonymous)]
}
 > mersenne.MersenneTwister19937
[Function: MersenneTwister19937]

No setup appears to be required beyond simply installing node and the 
node library and using node's 'require' function, so I don't think we 
need documentation for this in Guix (I'm assuming that node documents 
'require'), though I suppose we could have it for completeness  (*).  If 
doing that is considered a good thing, it seems to me that it should 
then also be done for Guile, Python, C/C++/etc, Minetest, Vim, ...

Greetings,
Maxime.

(*) E.g., when looking for the 'require' function, there was initially 
some slight confusion with 'require' accepting relative and absolute 
file names so I was fearing it might need to be passed 
$GUIX_ENVIRONMENT/lib/node_modules, but this turned out to be unfounded.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: developing javascript with guix

[jgart]

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.

How are users supposed to know to run node and node-mersenne?:

> $ guix shell node-mersenne node
> $ node
>  > mersenne = require('mersenne')

A new js developer Guixer will be frustrated if they have to learn this
through trial and error or by hanging out in the irc channel long enough
to find out that insight on how to do this.

Also, not every js developer will run code from a repl in their usual
workflow. So, I think we should see what the js community does as common
practices for loading js libraries and see if Guix could support that
since this will be too disruptive for a js developer to adopt Guix if
the workflow is radically different or completely undocumented. We should
document and show them what to expect when using Guix with js libraries.

> doing that is considered a good thing, it seems to me that it should 
> then also be done for Guile, Python, C/C++/etc, Minetest, Vim, ...

I completely agree that it should be done for all of our supported
language ecosystems.

To give an example from Common Lisp,

The common lisp community mostly uses quicklisp if they are not using
roswell.

Since Guix is a replacement for quicklisp, it asks users to understand
how to load libraries via asdf which is a low level detail for most common
lispers using quicklisp. I know this from my personal experiences. Phoe,
a prominent lisper in the community, for example, uses quicklisp mostly,
and does not usally load libraries from the asdf API in his workflow. The
same can be said for other prominent lispers I've conversed with.

If we are asking CL users to use asdf, which is not the most common way to
load libraries in the CL community then we should document in the CL Guix
documentation section how lispers should load CL code when using Guix.

I realize that we may not know the right approach yet because very few
common lispers use Guix.

The other thing regarding CL that should be mentioned is the fact that
you can not load lisp libraries dynamically in the repl or editor buffer
without restarting the shell environment. This is a common expectation
in the CL community and we should atleast make a note that they will
not be able to do that dynamicaly in a repl when using Guix currently.
If we do not want to support that because of our thesis or commitments
or some other reason then we should document it for CL users.

I think there are some efforts by charje to implement this but I'd have
to dig it up from the mailing list archives. I can link that if anyone
is interested.

> (*) E.g., when looking for the 'require' function, there was initially 
> some slight confusion with 'require' accepting relative and absolute 
> file names so I was fearing it might need to be passed 
> $GUIX_ENVIRONMENT/lib/node_modules, but this turned out to be unfounded.

Does this happen consistently/successfully across all languages supported by Guix?

Sorry for my long rant above. I just want to make sure I document my
experiences with these language ecoystems and their interaction with Guix
tooling so that we can see where we can improve regarding documentation,
user interface, as well as improving the Guixer's developer experience.

all best,

jgart

https://whereis.みんな/

https://phoe.github.io/
https://github.com/charje/

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

Re: developing javascript with guix

[Luis Felipe]

[-- Attachment #1.1: Type: text/plain, Size: 5270 bytes --]

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 :)

[-- Attachment #1.2: publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc --]
[-- Type: application/pgp-keys, Size: 1815 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]

Re: developing javascript with guix

[bokr]

On +2022-07-30 13:40:46 +0000, Luis Felipe wrote:
> 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 :)

pub   RSA 2048/7A39C6A9 2020-07-23 luis.felipe.la@protonmail.com <luis.felipe.la@protonmail.com>
> sub   RSA 2048/E8573DB1 2020-07-23
> 

I like to have stuff available off line
(and therefore also serving as distributed backup if^H^H when things disappear :)

So whatever you provide on the internet, I would like an easy way to clone what's
being served, so I can see it in the same way but locally on my laptop or lan.

I think IWBN to import web site contents via installing/updating
a guix package, maybe based on a git repo of web site (so it's also
available to users not yet having guix installed, i.e., so a simple
snippet could also put it in
    http://localhost/guix/
) (with safety-sanitizing).

I notice that my laptop system (pureos derivative of debian) starts up
an instance of apache2. Maybe yours des too?
--8<---------------cut here---------------start------------->8---
[17:05 ~/bs]$ ps -ef|grep apache
root       791     1  0 13:53 ?        00:00:00 /usr/sbin/apache2 -k start
www-data   793   791  0 13:53 ?        00:00:00 /usr/sbin/apache2 -k start
www-data   794   791  0 13:53 ?        00:00:00 /usr/sbin/apache2 -k start
bokr      5531  2173  0 17:05 pts/0    00:00:00 grep apache
--8<---------------cut here---------------end--------------->8---

On my laptop, the command
--8<---------------cut here---------------start------------->8---
firefox-esr http://localhost/
--8<---------------cut here---------------end--------------->8---
brought up a default test page [1], which suggests to me that
we could make a guix package to install any desired docs or files
that apache2 can serve, and make them accessible to your
preferred browser via something like

--8<---------------cut here---------------start------------->8---
firefox-esr http://localhost/guix/index.html
--8<---------------cut here---------------end--------------->8---

WDYT?

[1] -- after the default page came up, I selected and copied the text
and got the following, justifying for better reading here (or interfering
with your presenter's line wrapper, sorry if so :)

--8<---------------cut here---------------start------------->8---
[17:05 ~/bs]$ wl-paste |tr -d $'\r'|blockjust -left=0 -width=60
--8<---------------cut here---------------end--------------->8---
produced:

--8<---------------cut here---------------start------------->8---
This is a modified index.html

This is the default welcome page used to test the correct
operation of the Apache2 server after installation on Debian
systems. If you can read this page, it means that the Apache
HTTP server installed at this site is working properly. You
should replace this file (located at
/var/www/html/index.html) before continuing to operate your
HTTP server.

If you are a normal user of this web site and don't know
what this page is about, this probably means that the site
is currently unavailable due to maintenance. If the problem
persists, please contact the site's administrator.

By default, Debian does not allow access through the web
browser to any file apart of those located in /var/www,
public_html directories (when enabled) and /usr/share (for
web applications). If your site is using a web document root
located elsewhere (such as in /srv) you may need to
whitelist your document root directory in
/etc/apache2/apache2.conf.

The default Debian document root is /var/www/html. You can
make your own virtual hosts under /var/www. This is
different to previous releases which provides better
security out of the box. Reporting Problems

Please use the reportbug tool to report bugs in the Apache2
package with Debian. However, check existing bug reports
before reporting a new bug.

Please report bugs specific to modules (such as PHP and
others) to respective packages, not to the web server
itself.
--8<---------------cut here---------------end--------------->8---

--
Regards,
Bengt Richter

Re: developing javascript with guix

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 580 bytes --]


On 28-07-2022 00:25, jgart wrote:
> How are users supposed to know to run node and node-mersenne?:

They know that, because that was the premise of what they were trying to do:

You wrote: "how does a js developer use `guix shell` to load a js line 
like node-rimraf in a repl currently`:

In particular: "load a js like node-rimraf" = run node-rimraf (or in my 
example, node-mersenne).

Also, given that the question contains 'node-SOMETHING', I think it's 
clear that they wanted to use the _node_ REPL (and not, say, the Guile 
REPL).

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: developing javascript with guix

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 330 bytes --]


On 28-07-2022 01:15, Ryan Prior wrote:
>   At a minimum, can we make `guix shell` warn on stderr if you create a shell with one or more libraries but no interpreter?
I suppose, but this isn't `guix shell` specific really, it hold for all 
users of profiles (including "guix environment", "guix system", "guix 
home", ...).

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: developing javascript with guix

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 920 bytes --]


On 28-07-2022 01:15, Ryan Prior wrote:
> Why isn't node a dependency for node-mersenne though?

It is. node-mersenne uses node-build-system, which has node (or 
node-lts, dunno) in its implicit inputs.

Did you mean: 'Why isn't node propagated?'

For the same reasons as why any plugins don't propagate the thing they 
are plugging in, and why any library doesn't propagate its interpreter:

  * There is more than one implementation, how would Guix know which one
    you'd like?
  * Propagation stops you from separately updating the library and the
    interpreter (with "guix package -u this-package", or time machines,
    or defining a package variant).  (Actually, "guix package -u
    this-package" will ‘succeed’ because collision detection is disabled
    IIUC, but you can't decide which one wins)
  * ???

Also, see my answer on 'Is there really a use case for shipping ...’.


[-- Attachment #1.1.1.2: Type: text/html, Size: 1492 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: developing javascript with guix

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 779 bytes --]


On 28-07-2022 01:15, Ryan Prior wrote:
> Is there really a use case for shipping the source code of a JavaScript library without the interpreter?

Yes -- see "guix build --source" (it's not JavaScript-specific).

If you meant the _compiled_ JavaScript library (result of "guix build 
node-...") (even when it's maybe just copying source code around and 
maybe minimisation), then also yes:

JavaScript isn't only used in node, but also on the web, in browsers. 
While not all node-based libraries are usable on the web, I'd assume 
some of them are.  So it would be nice if "guix shell -D 
the-web-server-app-thing" didn't install the node interpreter you didn't 
ask for (functional package management) and don't need (resource savings).

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: developing javascript with guix

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 4034 bytes --]

TL;DR: I disagree with many of the claims, I agree that some 
documentation using specific examples is useful, I disagree that this 
isn't what we are already doing in the Guix manual, I agree that we 
don't have per-language landing pages yet and that they could be a 
convenient starting point, I disagree on the degree to which this is 
useful, I disagree that this is required.

On 28-07-2022 01:15, Ryan Prior wrote:
> ## 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/
Neither does the Guix package manager take for granted you know anything 
about the language -- the package management commands are 
language-independent in Guix. (imports are another matter, but those are 
a language manner, which Guix is not involved with). Also, AFAICT, that 
workflow is not Python-specific but PyPi+pip-specific, except for the 
"python3 --version" check. It also seems abstract to me, i.e., it 
doesn't mention any specific packages to install for some project but 
uses abstract commands like "python3 -m pip install "Foo==some-version", 
nothing concrete?
>
> We could write a guide like that

We already have one: see (guix)Getting Started.

> with information and example commands specific to Python packaging, and another for JavaScript, etc.
These commands are not language-specific in Guix.
> 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.

Context and examples exist in (guix)Getting Started (example: Emacs, 
context: Getting Started,.

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

"guix search node mersenne" -> node-mersenne
"guix search python mersenn" -> no results (can happen)

"guix search python aes" -> some python libraries implementing AES
"guix search node aes" -> likewise, no results.
"guix search rust aes" -> many results

No tags or categories are needed if the descriptions are good. Maybe 
this can be mentioned among the examples in (guix)Invoking guix package?

>   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.
Myself, I doubt that this will give much assurance or help them beyond 
what the docs already do, but I suppose we could make a few 
language-specific 'cheat sheets' of sorts, which seems to be the kind of 
thing you are referring to?  E.g.,:

* Install the Python interpreter: $ guix install python

   (see (guix).... for more info on "guix install")

* Install some Python libraries: $ guix install python-thisexample 
python-thatexample
* Search for Python libraries: $ guix search python more-keywords...

   (see [...] for more info on [...])

   Example: search for Python cryptography libraries: $ guix search 
python crypto ...

* Start the Python interpreter: $ python3

* Start Python and import some libraries:

   $ python3

   import foobar

   (see https://some-python-site on how to use imports in Python.)

   Important: the package name does not always match the name used in 
Python!.

I don't think this brings much, but not much is still a little, and a 
little is still useful.

If there is interest, such workflows could be worked out in prose.

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: developing javascript with guix

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Hi Ryan,

Ryan Prior <rprior@protonmail.com> writes:

[...]

> Meanwhile, in the Guix docs, everything is abstract.

Speaking of the Guix Manual, abstraction is The Good Thing to do, IMHO
:-)

[...]

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

what about specific "Developing with your preferred language in Guix"
language subsections in The Coockbook, also available offline in
texinfo?

could you please propose patches for one of the languages you have
experience with?

I guess that similar subsections could also document the "state of the
art" (aka issues) with packaging libraries in that language (like rust,
for esemple)

> and package search

I guess searching specific language libraries isn't an issue, even if we
miss "Category" or "Language" in packages metadata, no?

[...]

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: developing javascript with guix

[david larsson]

On 2022-07-30 15:40, Luis Felipe wrote:

> 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'd also like to have a place for this information collected and shared.

Another option, not to imply it's a better one, but maybe worth 
considering, is the libreplanet guix wiki. I think that basically anyone 
can edit the page there, and it would be a smaller barrier of entry to 
contribute (for good and bad).

For guile development there's the information in help-guix with subject: 
"Configuring geiser for load paths of Guix environment", that would be 
useful to add.

For python: I have a setup with emacs, emacs-jedi and jupyter in a nice 
way, and I was leaning towards just sharing it on some git repo of mine, 
which would be a waste when it can be shared with a wider guix audience 
if we had a set place for it. Personally, I'd be more likely to get 
around to share it on the libreplanet wiki, than by sending a patch to 
the guix website. Maybe the website can point to the correct wiki 
subpage from the "software development" (in your field) page?

Best regards,
David