IT jobs in Switzerland

[Gábor Boskovits]

Hello guix,

The firm where I am working now is hiring.

Location: Zug, Switzerland. People willing to work in office will be
preferred. The firm helps with relocation if needed.

Profile: HFT crypto startup

Codebase: c++, python
Tooling: k8s, gitlab

Positions: quantitative trader, quantitative researcher, c++ developer,
devops

Experience with AWS is a plus.

If someone is willing to give this a try, please come back to me and I can
provide more details.

Regards,
g_bor

Re: branch master updated (a737f2f -> 0454910)

[Leo Famulari]

On Wed, Sep 22, 2021 at 02:48:30PM -0400, guix-comm...@gnu.org wrote:
> lfam pushed a change to branch master
> in repository guix.
> 
>  new 443740b  gnu: linux-libre 5.14: Update to 5.14.7.
>  new ce45cd6  gnu: linux-libre 5.10: Update to 5.10.68.
>  new ce690cb  gnu: linux-libre 5.4: Update to 5.4.148.
>  new 36becc5  gnu: linux-libre 4.19: Update to 4.19.207.
>  new 66758aa  gnu: linux-libre 4.14: Update to 4.14.247.
>  new 57a872e  gnu: linux-libre 4.9: Update to 4.9.283.
>  new 0454910  gnu: linux-libre 4.4: Update to 4.4.284.

I just realized that I pushed these commits too hastily: they aren't
released upstream yet. I was able to make use of local caching of the
previous deblob script releases to build the tarballs for these
packages.

I'm going to revert the commits for now...


signature.asc
Description: PGP signature

Re: “What’s in a package”

[zimoun]

Hi,

On Tue, 21 Sep 2021 at 15:20, Katherine Cox-Buday  
wrote:

>  I.e.,
> when trying to achieve a goal, it is a pain to package things that
> aren't yet packaged, but what I get in return are sane environments,
> deployments, and meta-data about all of these.

I concur! :-)

> This is perhaps a rehash of the "worse is better"[2] conversation, but
> I often struggle with deciding whether to do things the "fast" way, or
> the "correct" way. I think when your path is clear, the correct way
> will get you farther, faster. But when you're doing experiments, or
> exploratory programming, being bogged down with the "correct" way of
> doing things (i.e. Guix packages) might take a lot of time for no
> benefit. E.g. maybe you end up packaging a cluster of things that you
> find out don't work out for you. Of course the challenge is: if you
> choose the fast way, and it works out, do you got back to do it the
> correct way so that you're on sound footing?
>
> Bringing this back to Guix, and maybe the GNU philosophy, it has been
> very helpful for me to be able to leverage the flexibility of Guix to
> occasionally do things the "fast" way, perhaps by packaging a
> binary. Paradoxically, it has allowed me to stay within the Guix and
> free software ecosystem. In my opinion, flexibility is key to growing
> the ecosystem and community, and I would encourage Guix as a project
> to take every opportunity to give the user options.

Long time ago, I watched this badly recorded video [1] about “Haskell is
useless”.  I reframe for packages the exposed double-axis:

 useful  | trad-pkg ~~>Nirvana
 | ^
 | | Guix
useless  |   
 ---
  unsafesafe

where ’unsafe’ vs ’safe’ could read ’fast’ vs ’robust’; and trad-pkg
reads apt, conda, spack, yum, etc.


1: 


Cheers,
simon

Re: “What’s in a package”

[Pjotr Prins]

Great post Ludovic! We are contributors, consumers and fans of GNU
Guix for good reason.

On Wed, Sep 22, 2021 at 12:08:15AM +0530, Arun Isaac wrote:
> 
> Hi Ludo,
> 
> >   https://hpc.guix.info/blog/2021/09/whats-in-a-package/
> 
> Thanks for writing this article! This article will be very useful to
> share with others who might think our insistence on auditability,
> reproducibility and software freedom to be bordering on the
> pedantic. Frankly, I find it quite mysterious why Guix is not more
> widely adopted in science. But, I suppose we will get there, in time!
> :-)
> 
> Cheers,
> Arun

Re: [Spam:]Re: “What’s in a package”

[Konrad Hinsen]

Katherine Cox-Buday  writes:

> As we've seen these past years with COVID-19 and the world's supply
> chains, efficiency has some kind of inverse relationship with
> robustness. If you go too far down the path of efficiency, you are not
> very flexible, and you're building sand castles.

That's exactly what I have seen happening in scientific software for a
while :

  https://hal.archives-ouvertes.fr/hal-02117588

> It's for this reason I appreciate having "robust" software underneath
> my sand castle. At least I know only so much can crumble :)

100 % agreement!

> I want to be careful here in what I suggest. I think it is very
> important that Guix remain a bastion of robust software with very high
> standards. I don't want to see the PyPi PyTorch packages of the world

Me neither. My suggestion was for support in Guix the tool, not Guix the
software distribution. People can/should package their sand castles in
their private channels.

> So with your example: make it really easy to transform that PyPi
> package into a terrible Guix primitive of some kind, but don't let me
> commit it to Guix proper.

I trust our maintainer team to not let this happen.

> Maybe interactive software that introspects how a package
> is written and behaves at runtime (in a container?) and utilizes the
> homoiconicity of scheme to suggest modifications of the package, or
> next steps. E.g. expand the linter to suggest things like

That sounds interesting!

> Speaking of industry, I don't think we leverage software to build software 
> enough.

Definitely not.

> And by the way, none of those ideas would be possible if Guix weren't
> such a robust and sane ecosystem.

Exactly. We can discuss (and more) adding sloppy stuff on top of Guix,
but it wouldn't work the other way round.


"Jonathan McHugh"  writes:

> Your focus regarding a transition from exploratory to robust is
> important (though may have equal significance in the other
> direction?).

Not equal as I see it, but yes, it matters as well, for dragging a
stable package out int the open again for significant improvements.

> Would security experts have (understandable) criteria to prioritise
> choices for 'robust corridors' within an ecosystem of sourcefiles and
> encapsulated blobs?

I'd love to hear from security experts too!

Konrad.

Re: Wireguard

[Maxime Devos]

crodges schreef op wo 22-09-2021 om 09:03 [-0700]:
> On Wednesday, September 1, 2021 12:07:43 A.M. PDT Maxime Devos wrote:
> > crodges schreef op zo 29-08-2021 om 14:53 [-0700]:
> > > Hello everyone,
> > > 
> > > Let me start thanking you for developing such a interesting project in GNU
> > > Guix. Also, I don't want to take up anyone's time, so you can just point
> > > to
> > > documentation or other resource succinctly and I'll do my best. I'm
> > > writing
> > > here because I tried the help list but not answer so far, after a few
> > > days.
> > > 
> > > I managed to configure wireguard on a vps running guix and created clients
> > > for my desktop and cellphone. What I want to do (and did already in a
> > > Debian vps) is to make wireguard's lan accessible to anyone connected and
> > > also browse the internet using this vpn.
> > 
> > The Wireguard service as defined in Guix System doesn't currently support
> > the forwarding you appear to describe ...
> > 
> > > As I remember, I need to allow ip forwarding using
> > > 
> > > sysctl net.ipv4.ip_forward=1
> > > 
> > > and I also need to put these rules into wireguard (the server) under
> > > [interface],
> > > 
> > > PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A
> > > POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT;
> > > ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > > 
> > > PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D
> > > POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT;
> > > ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> > 
> > However, I don't see why this couldn't be implemented in Guix System
> > (after some changes to wireguard-service-type).
> > 
> > > Problem is, looking at the latest guix manual, PostUp and PostDown doesn't
> > > seem to exist yet. Do they exist but are still undocumented?
> > 
> > Guix uses "wg-quick", so it would seem they do exist, but are inaccessible
> > from Guix.  The configuration file is created in
> > wireguard-configuration-file (in gnu/services/vpn.scm), maybe you can
> > modify that.
> > 
> > > If they don't exist, where should be a reasonable place to add this
> > > configurations?
> > 
> >  and wireguard-configuration-file in (gnu services
> > vpn) it would seem.  Also, sysctl-service-type would need to be extended
> > (in the ‘service-extension’ meaning of the word) to set net.ipv4.ip_forward
> > appropriately.
> > 
> > > I'm trying to do everything the guix way, when I finish this
> > > machine configuration, I'd like it to be fully replicable.
> > > 
> > > Also, is this something that I could solve modifying the wireguard service
> > > definition itself?
> > 
> > If replicability is all you need, you could add ‘postdown’ and ‘postup’
> > options to , which would need to be set to the
> > commands above.  However, these strings seem rather complicated for the
> > uninitiated, so I'd recommend something more high-level instead.  Some
> > interface like
> > 
> >   (wireguard-configuration
> > [...]
> > (addresses ...)
> > (peers ...)
> > (forward? #t))
> > 
> > perhaps?  Make sure to add some documentation to ‘Wireguard’ in (guix)VPN
> > Services. (Maybe add some example situations on how forward? can be used
> > and how it functions.)
> > 
> > I want to note that I don't understand what exactly you're doing, I only
> > understand that there is some forwarding going on, and I'm not unfamiliar
> > with networking issue (e.g. I recently figured out why I couldn't connect
> > to the Internet with the ISP-provided ‘4G minimodem’ -- DNS was b0rken). 
> > So explaining forward? to laypeople might take some care.
> > 
> > Writing a corresponding ‘system test’ in gnu/tests/networking.scm is
> > recommended.
> > 
> > Greetings,
> > Maxime.
> Thanks for the pointers Maxime.
> 
> I'm not an expert in networking but I can briefly tell about my use case here.
> basically my setup accomplishes two things: any machine connected to the 
> server running guix and wireguard should be able to browse the internet like 
> a 
> normal vpn (using the server's ip address) and any client theoretically could 
> see each other. Right now I use this capability to play 0ad with friends, in 
> the future there will be apps running in different clients, accessible to 
> anyone inside vpn.
> 
> That said, I'm back here to ask one more thing. I cloned guix and followed 
> the 
> manual to create an --pure environment and authenticated the commits. This 
> machine is a different one from my server, here I have guix running on top of 
> manjaro (an arch gnu/linux flavor).
> 
> I started changing code inside vpn.scm and my approach was to "make && make 
> check" after changes to see if it would still build. But this week, after a 
> git pull to update the repo and using make, I'm now greeted with
> 
> error: failed to load 'gnu/packages/perl.scm':
> ice-9/eval.scm:293:34: In procedure abi-check: #>: 
> record ABI 

Re: Wireguard

[crodges]

On Wednesday, September 22, 2021 9:03:58 A.M. PDT crodges wrote:
> On Wednesday, September 1, 2021 12:07:43 A.M. PDT Maxime Devos wrote:
> > crodges schreef op zo 29-08-2021 om 14:53 [-0700]:
> > > Hello everyone,
> > > 
> > > Let me start thanking you for developing such a interesting project in
> > > GNU
> > > Guix. Also, I don't want to take up anyone's time, so you can just point
> > > to
> > > documentation or other resource succinctly and I'll do my best. I'm
> > > writing
> > > here because I tried the help list but not answer so far, after a few
> > > days.
> > > 
> > > I managed to configure wireguard on a vps running guix and created
> > > clients
> > > for my desktop and cellphone. What I want to do (and did already in a
> > > Debian vps) is to make wireguard's lan accessible to anyone connected
> > > and
> > > also browse the internet using this vpn.
> > 
> > The Wireguard service as defined in Guix System doesn't currently support
> > the forwarding you appear to describe ...
> > 
> > > As I remember, I need to allow ip forwarding using
> > > 
> > > sysctl net.ipv4.ip_forward=1
> > > 
> > > and I also need to put these rules into wireguard (the server) under
> > > [interface],
> > > 
> > > PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A
> > > POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j
> > > ACCEPT;
> > > ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > > 
> > > PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D
> > > POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j
> > > ACCEPT;
> > > ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> > 
> > However, I don't see why this couldn't be implemented in Guix System
> > (after some changes to wireguard-service-type).
> > 
> > > Problem is, looking at the latest guix manual, PostUp and PostDown
> > > doesn't
> > > seem to exist yet. Do they exist but are still undocumented?
> > 
> > Guix uses "wg-quick", so it would seem they do exist, but are inaccessible
> > from Guix.  The configuration file is created in
> > wireguard-configuration-file (in gnu/services/vpn.scm), maybe you can
> > modify that.
> > 
> > > If they don't exist, where should be a reasonable place to add this
> > > configurations?
> > 
> >  and wireguard-configuration-file in (gnu
> > services
> > vpn) it would seem.  Also, sysctl-service-type would need to be extended
> > (in the ‘service-extension’ meaning of the word) to set
> > net.ipv4.ip_forward
> > appropriately.
> > 
> > > I'm trying to do everything the guix way, when I finish this
> > > machine configuration, I'd like it to be fully replicable.
> > > 
> > > Also, is this something that I could solve modifying the wireguard
> > > service
> > > definition itself?
> > 
> > If replicability is all you need, you could add ‘postdown’ and ‘postup’
> > options to , which would need to be set to the
> > commands above.  However, these strings seem rather complicated for the
> > uninitiated, so I'd recommend something more high-level instead.  Some
> > interface like
> > 
> >   (wireguard-configuration
> >   
> > [...]
> > (addresses ...)
> > (peers ...)
> > (forward? #t))
> > 
> > perhaps?  Make sure to add some documentation to ‘Wireguard’ in (guix)VPN
> > Services. (Maybe add some example situations on how forward? can be used
> > and how it functions.)
> > 
> > I want to note that I don't understand what exactly you're doing, I only
> > understand that there is some forwarding going on, and I'm not unfamiliar
> > with networking issue (e.g. I recently figured out why I couldn't connect
> > to the Internet with the ISP-provided ‘4G minimodem’ -- DNS was b0rken).
> > So explaining forward? to laypeople might take some care.
> > 
> > Writing a corresponding ‘system test’ in gnu/tests/networking.scm is
> > recommended.
> > 
> > Greetings,
> > Maxime.
> 
> Thanks for the pointers Maxime.
> 
> I'm not an expert in networking but I can briefly tell about my use case
> here. basically my setup accomplishes two things: any machine connected to
> the server running guix and wireguard should be able to browse the internet
> like a normal vpn (using the server's ip address) and any client
> theoretically could see each other. Right now I use this capability to play
> 0ad with friends, in the future there will be apps running in different
> clients, accessible to anyone inside vpn.
> 
> That said, I'm back here to ask one more thing. I cloned guix and followed
> the manual to create an --pure environment and authenticated the commits.
> This machine is a different one from my server, here I have guix running on
> top of manjaro (an arch gnu/linux flavor).
> 
> I started changing code inside vpn.scm and my approach was to "make && make
> check" after changes to see if it would still build. But this week, after a
> git pull to update the repo and using make, I'm now greeted with
> 
> error: failed to load 'gnu/packages/perl.scm':
> 

Re: Wireguard

[crodges]

On Wednesday, September 1, 2021 12:07:43 A.M. PDT Maxime Devos wrote:
> crodges schreef op zo 29-08-2021 om 14:53 [-0700]:
> > Hello everyone,
> > 
> > Let me start thanking you for developing such a interesting project in GNU
> > Guix. Also, I don't want to take up anyone's time, so you can just point
> > to
> > documentation or other resource succinctly and I'll do my best. I'm
> > writing
> > here because I tried the help list but not answer so far, after a few
> > days.
> > 
> > I managed to configure wireguard on a vps running guix and created clients
> > for my desktop and cellphone. What I want to do (and did already in a
> > Debian vps) is to make wireguard's lan accessible to anyone connected and
> > also browse the internet using this vpn.
> 
> The Wireguard service as defined in Guix System doesn't currently support
> the forwarding you appear to describe ...
> 
> > As I remember, I need to allow ip forwarding using
> > 
> > sysctl net.ipv4.ip_forward=1
> > 
> > and I also need to put these rules into wireguard (the server) under
> > [interface],
> > 
> > PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A
> > POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT;
> > ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > 
> > PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D
> > POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT;
> > ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> 
> However, I don't see why this couldn't be implemented in Guix System
> (after some changes to wireguard-service-type).
> 
> > Problem is, looking at the latest guix manual, PostUp and PostDown doesn't
> > seem to exist yet. Do they exist but are still undocumented?
> 
> Guix uses "wg-quick", so it would seem they do exist, but are inaccessible
> from Guix.  The configuration file is created in
> wireguard-configuration-file (in gnu/services/vpn.scm), maybe you can
> modify that.
> 
> > If they don't exist, where should be a reasonable place to add this
> > configurations?
> 
>  and wireguard-configuration-file in (gnu services
> vpn) it would seem.  Also, sysctl-service-type would need to be extended
> (in the ‘service-extension’ meaning of the word) to set net.ipv4.ip_forward
> appropriately.
> 
> > I'm trying to do everything the guix way, when I finish this
> > machine configuration, I'd like it to be fully replicable.
> > 
> > Also, is this something that I could solve modifying the wireguard service
> > definition itself?
> 
> If replicability is all you need, you could add ‘postdown’ and ‘postup’
> options to , which would need to be set to the
> commands above.  However, these strings seem rather complicated for the
> uninitiated, so I'd recommend something more high-level instead.  Some
> interface like
> 
>   (wireguard-configuration
> [...]
> (addresses ...)
> (peers ...)
> (forward? #t))
> 
> perhaps?  Make sure to add some documentation to ‘Wireguard’ in (guix)VPN
> Services. (Maybe add some example situations on how forward? can be used
> and how it functions.)
> 
> I want to note that I don't understand what exactly you're doing, I only
> understand that there is some forwarding going on, and I'm not unfamiliar
> with networking issue (e.g. I recently figured out why I couldn't connect
> to the Internet with the ISP-provided ‘4G minimodem’ -- DNS was b0rken). 
> So explaining forward? to laypeople might take some care.
> 
> Writing a corresponding ‘system test’ in gnu/tests/networking.scm is
> recommended.
> 
> Greetings,
> Maxime.
Thanks for the pointers Maxime.

I'm not an expert in networking but I can briefly tell about my use case here.
basically my setup accomplishes two things: any machine connected to the 
server running guix and wireguard should be able to browse the internet like a 
normal vpn (using the server's ip address) and any client theoretically could 
see each other. Right now I use this capability to play 0ad with friends, in 
the future there will be apps running in different clients, accessible to 
anyone inside vpn.

That said, I'm back here to ask one more thing. I cloned guix and followed the 
manual to create an --pure environment and authenticated the commits. This 
machine is a different one from my server, here I have guix running on top of 
manjaro (an arch gnu/linux flavor).

I started changing code inside vpn.scm and my approach was to "make && make 
check" after changes to see if it would still build. But this week, after a 
git pull to update the repo and using make, I'm now greeted with

error: failed to load 'gnu/packages/perl.scm':
ice-9/eval.scm:293:34: In procedure abi-check: #>: 
record ABI mismatch; recompilation needed

I will still spend some time with this error, but I found worth to ask: is 
this approach of "make && make check" a reasonable one? Is there a way to test 
a guix system without installing it? Packages I know we can, but system 
capabilities 

Re: [Spam:]Re: “What’s in a package”

[Jonathan McHugh]

Hi Konrad,

Similarly I found the post excellent.

Your focus regarding a transition from exploratory to robust is important 
(though may have equal significance in the other direction?).

Would security experts have (understandable) criteria to prioritise choices for 
'robust corridors' within an ecosystem of sourcefiles and encapsulated blobs?


Jonathan McHugh
indieterminacy@libre.brussels

September 22, 2021 3:32 PM, "Konrad Hinsen"  wrote:

> Hi Katherine and Ludo,
> 
>> I appreciate this post very much. Setting aside questions of freedom,
> 
> +1
> 
>> This is perhaps a rehash of the "worse is better"[2] conversation, but
>> I often struggle with deciding whether to do things the "fast" way, or
>> the "correct" way. I think when your path is clear, the correct way
>> will get you farther, faster. But when you're doing experiments, or
>> exploratory programming, being bogged down with the "correct" way of
>> doing things (i.e. Guix packages) might take a lot of time for no
> 
> Exactly. Most software engineering tools situate themselves somewhere on
> the "fast" vs. "robust" scale, and defend their position as the one and
> only Good Thing. Guix is at the "robust" end of the scale in the
> software management category. And that's what I want for most of the
> software I use, i.e. everything I don't hack on myself. Which is why I
> like Guix :-)
> 
> What is so far insufficiently supported by computing technology is the
> necessary transition from "fast" to "robust". There are a few
> exceptions, such as programming language with gradual typing. In most
> situations, moving software from exploratory to robust involves a lot of
> rewriting, often manually, with no tooling support.
> 
>> Bringing this back to Guix, and maybe the GNU philosophy, it has been
>> very helpful for me to be able to leverage the flexibility of Guix to
>> occasionally do things the "fast" way, perhaps by packaging a
>> binary. Paradoxically, it has allowed me to stay within the Guix and
>> free software ecosystem. In my opinion, flexibility is key to growing
>> the ecosystem and community, and I would encourage Guix as a project
>> to take every opportunity to give the user options.
> 
> +100 :-)
> 
> There is a lot we can improve here. Tutorials would be a good start.
> Example: How do you package a binary in Guix? In particular, how do you
> deal with binaries that have binary dependencies that they expect in
> /lib etc.? A next step would be tool support: Grab whatever PyPI offers,
> even if it's only binary wheels, and turn that into a Guix package.
> 
> Another aspect would be supporting software development moving from fast
> to robust. Suppose I have software I compile by hand, or via a simple
> Makefile, somewhere in my home directory. How do I go from there to (1)
> a quick-and-dirty Guix package, then (2) a very basic publishable Guix
> package and finally (3) a Guix package with tests and documentation?
> The path should be supported by various tools, from automatic rewriting
> to debugging. As an example, something I have wished for more than once
> is the possibility to run the individual build steps of a Guix package
> under my own account in my home directory, for debugging purposes.
> 
> Konrad
> --
> -
> Konrad Hinsen
> Centre de Biophysique Moléculaire, CNRS Orléans
> Synchrotron Soleil - Division Expériences
> Saint Aubin - BP 48
> 91192 Gif sur Yvette Cedex, France
> Tel. +33-1 69 35 97 15
> E-Mail: konrad DOT hinsen AT cnrs DOT fr
> http://dirac.cnrs-orleans.fr/~hinsen
> ORCID: https://orcid.org/-0003-0330-9428
> Twitter: @khinsen
> -

Re: [Spam:]Re: “What’s in a package”

[Katherine Cox-Buday]

Konrad Hinsen  writes:

> What is so far insufficiently supported by computing technology is the
> necessary transition from "fast" to "robust".

This is really a large problem in the industry. Especially since in most 
circles moving fast is considered the preferred way to do things. SaaS and 
abstractions are endemic, and while helpful to get things going, it can lead to 
precarious systems with interdependencies and risks that are not fully 
understood or appreciated.

The "fast" path does allow people to test out new ideas very quickly, but there 
is a hidden cost. As we've seen these past years with COVID-19 and the world's 
supply chains, efficiency has some kind of inverse relationship with 
robustness. If you go too far down the path of efficiency, you are not very 
flexible, and you're building sand castles.

It's for this reason I appreciate having "robust" software underneath my sand 
castle. At least I know only so much can crumble :)

> There are a few exceptions, such as programming language with gradual typing.
> In most situations, moving software from exploratory to robust involves a lot
> of rewriting, often manually, with no tooling support.

I really like this framing. How can we support every step of the continuum with 
a gentle pull towards robustness? That sounds like something to strive for.

>> Bringing this back to Guix, and maybe the GNU philosophy, it has been
>> very helpful for me to be able to leverage the flexibility of Guix to
>> occasionally do things the "fast" way, perhaps by packaging a
>> binary. Paradoxically, it has allowed me to stay within the Guix and
>> free software ecosystem. In my opinion, flexibility is key to growing
>> the ecosystem and community, and I would encourage Guix as a project
>> to take every opportunity to give the user options.
>
> +100 :-)
>
> There is a lot we can improve here. Tutorials would be a good start.
> Example: How do you package a binary in Guix? In particular, how do you
> deal with binaries that have binary dependencies that they expect in
> /lib etc.? A next step would be tool support: Grab whatever PyPI offers,
> even if it's only binary wheels, and turn that into a Guix package.

I want to be careful here in what I suggest. I think it is very important that 
Guix remain a bastion of robust software with very high standards. I don't want 
to see the PyPi PyTorch packages of the world in Guix. I /do/ want to see 
tooling in Guix that allows users to package and utilize these things as 
first-class primitives in the Guix world.

In other words, let me create beautiful and terrible things, but don't let me 
unleash them on the world.

So with your example: make it really easy to transform that PyPi package into a 
terrible Guix primitive of some kind, but don't let me commit it to Guix proper.

> Another aspect would be supporting software development moving from fast
> to robust. Suppose I have software I compile by hand, or via a simple
> Makefile, somewhere in my home directory. How do I go from there to (1)
> a quick-and-dirty Guix package, then (2) a very basic publishable Guix
> package and finally (3) a Guix package with tests and documentation?
> The path should be supported by various tools, from automatic rewriting
> to debugging. As an example, something I have wished for more than once
> is the possibility to run the individual build steps of a Guix package
> under my own account in my home directory, for debugging purposes.

This kind of stuff really excites me. If we could build tooling that somehow 
moves things along the continuum, that would really be something. Maybe 
interactive software that introspects how a package is written and behaves at 
runtime (in a container?) and utilizes the homoiconicity of scheme to suggest 
modifications of the package, or next steps. E.g. expand the linter to suggest 
things like documentation, or to identify at what point on the continuum the 
package might currently be, and how to move forward. Does the package vendor 
binaries? Does Guix have any packages that look like those binaries? What does 
the packages binaries want to link to? What paths does it try and access when 
run?

Speaking of industry, I don't think we leverage software to build software 
enough.

And by the way, none of those ideas would be possible if Guix weren't such a 
robust and sane ecosystem.

-- 
Katherine

Re: [Spam:]Re: “What’s in a package”

[Konrad Hinsen]

Hi Katherine and Ludo,

> I appreciate this post very much. Setting aside questions of freedom,

+1

> This is perhaps a rehash of the "worse is better"[2] conversation, but
> I often struggle with deciding whether to do things the "fast" way, or
> the "correct" way. I think when your path is clear, the correct way
> will get you farther, faster. But when you're doing experiments, or
> exploratory programming, being bogged down with the "correct" way of
> doing things (i.e. Guix packages) might take a lot of time for no

Exactly. Most software engineering tools situate themselves somewhere on
the "fast" vs. "robust" scale, and defend their position as the one and
only Good Thing. Guix is at the "robust" end of the scale in the
software management category. And that's what I want for most of the
software I use, i.e. everything I don't hack on myself. Which is why I
like Guix :-)

What is so far insufficiently supported by computing technology is the
necessary transition from "fast" to "robust". There are a few
exceptions, such as programming language with gradual typing. In most
situations, moving software from exploratory to robust involves a lot of
rewriting, often manually, with no tooling support.

> Bringing this back to Guix, and maybe the GNU philosophy, it has been
> very helpful for me to be able to leverage the flexibility of Guix to
> occasionally do things the "fast" way, perhaps by packaging a
> binary. Paradoxically, it has allowed me to stay within the Guix and
> free software ecosystem. In my opinion, flexibility is key to growing
> the ecosystem and community, and I would encourage Guix as a project
> to take every opportunity to give the user options.

+100 :-)

There is a lot we can improve here. Tutorials would be a good start.
Example: How do you package a binary in Guix? In particular, how do you
deal with binaries that have binary dependencies that they expect in
/lib etc.? A next step would be tool support: Grab whatever PyPI offers,
even if it's only binary wheels, and turn that into a Guix package.

Another aspect would be supporting software development moving from fast
to robust. Suppose I have software I compile by hand, or via a simple
Makefile, somewhere in my home directory. How do I go from there to (1)
a quick-and-dirty Guix package, then (2) a very basic publishable Guix
package and finally (3) a Guix package with tests and documentation?
The path should be supported by various tools, from automatic rewriting
to debugging. As an example, something I have wished for more than once
is the possibility to run the individual build steps of a Guix package
under my own account in my home directory, for debugging purposes.

Konrad
-- 
-
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: konrad DOT hinsen AT cnrs DOT fr
http://dirac.cnrs-orleans.fr/~hinsen/
ORCID: https://orcid.org/-0003-0330-9428
Twitter: @khinsen
-