Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

[Zelphir Kaltstahl]

Hello Yasu,

There are some legal aspects about using the official "marketplace" from other 
than the official VSCode build: 
https://github.com/VSCodium/vscodium/blob/master/DOCS.md#extensions--marketplace 
at least according to the VSCodium linking to 
https://github.com/microsoft/vscode/issues/31168, wherein someone interpreted 
things: https://github.com/microsoft/vscode/issues/31168#issuecomment-1136375670.

Not sure this plays any role in your proposed process. It is something to keep 
in mind.

Regards,
Zelphir

On 7/11/23 18:00, help-guix-request@gnu.org wrote:
> Send Help-Guix mailing list submissions to
> 	help-guix@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.gnu.org/mailman/listinfo/help-guix
> or, via email, send a message with subject or body 'help' to
> 	help-guix-request@gnu.org
>
> You can reach the person managing the list at
> 	help-guix-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-Guix digest..."
>
>
> Today's Topics:
>
>     1. VSCode DevContainer for Guix? (Yasuaki Kudo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 11 Jul 2023 05:55:33 +0900
> From: Yasuaki Kudo <yasu@yasuaki.com>
> To: help-guix <help-guix@gnu.org>
> Subject: VSCode DevContainer for Guix?
> Message-ID: <BB9B5B1E-810C-4315-AD49-9FEC156F5E9E@yasuaki.com>
> Content-Type: text/plain; charset=utf-8
>
> Hello!!
>
> So I have just spent a month battling with Docker and VSCode for a project and became familiar with them.  Combining both, we can create a very pleasant and reproducible developer environment that everyone can copy.
>
> DevContainer is like Screen/Tmux on steroids - the heavy lifting of compilation and running can be shifted to a Docker, a remote SSH session, or a combination of both, while the end-programmer can interact with the local VSCode IDE.  And the developer-facing computer can be any of the 3 - Linux, Windows or Macintosh (inclusive of Apple custom CPU)
>
> A development team can share the exact same environment using this mechanism.
>
> I think we should have such a DecContainer for Guix programmers? 😄
>
> -Yasu
>
>
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Help-Guix mailing list
> Help-Guix@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-guix
>
>
> ------------------------------
>
> End of Help-Guix Digest, Vol 92, Issue 9
> ****************************************

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

[Yasuaki Kudo]

Thank you for this link Zelphir!

While I don't know much about this, it smells like the restrictions are the same sort that Chrome and Firefox put as the proprietary surface layered on top of the respective copyleft foundation?

I tried the de-microsofted VSCodium when I used to run GuixOS (Now I am back to Ubuntu) but it didn't work well so I left it at that 😅

My gut feeling is that Guix will excel at as niche and very efficient software packaging system and the popularity and adoption could expand from there. 

So I thought VSCode DevContainer could be a very good place to start!  

An example use case I can think of is for GitHub Actions continuous integration.  It seems to me that local SSD caching (10GB) is almost instantaneous. We can cache the Guix build dependencies there.  

Then, it will create a Docker image as an artifact from the CI-run.  The image is as small as it can be because Guix only installs the necessary software.  

This will be very beneficial because the artifact (Docker images) uploads/downloads seem to very slow!

This way, we can gradually introduce Guix to development teams as niche software for specific cases?  (The guix docker images will work together with many other docker images created in conventional ways)

-Yasu

> On Jul 12, 2023, at 04:23, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
> 
> Hello Yasu,
> 
> There are some legal aspects about using the official "marketplace" from other than the official VSCode build: https://github.com/VSCodium/vscodium/blob/master/DOCS.md#extensions--marketplace at least according to the VSCodium linking to https://github.com/microsoft/vscode/issues/31168, wherein someone interpreted things: https://github.com/microsoft/vscode/issues/31168#issuecomment-1136375670.
> 
> Not sure this plays any role in your proposed process. It is something to keep in mind.
> 
> Regards,
> Zelphir
> 
>> On 7/11/23 18:00, help-guix-request@gnu.org wrote:
>> Send Help-Guix mailing list submissions to
>>    help-guix@gnu.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>    https://lists.gnu.org/mailman/listinfo/help-guix
>> or, via email, send a message with subject or body 'help' to
>>    help-guix-request@gnu.org
>> 
>> You can reach the person managing the list at
>>    help-guix-owner@gnu.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Help-Guix digest..."
>> 
>> 
>> Today's Topics:
>> 
>>    1. VSCode DevContainer for Guix? (Yasuaki Kudo)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 11 Jul 2023 05:55:33 +0900
>> From: Yasuaki Kudo <yasu@yasuaki.com>
>> To: help-guix <help-guix@gnu.org>
>> Subject: VSCode DevContainer for Guix?
>> Message-ID: <BB9B5B1E-810C-4315-AD49-9FEC156F5E9E@yasuaki.com>
>> Content-Type: text/plain; charset=utf-8
>> 
>> Hello!!
>> 
>> So I have just spent a month battling with Docker and VSCode for a project and became familiar with them.  Combining both, we can create a very pleasant and reproducible developer environment that everyone can copy.
>> 
>> DevContainer is like Screen/Tmux on steroids - the heavy lifting of compilation and running can be shifted to a Docker, a remote SSH session, or a combination of both, while the end-programmer can interact with the local VSCode IDE.  And the developer-facing computer can be any of the 3 - Linux, Windows or Macintosh (inclusive of Apple custom CPU)
>> 
>> A development team can share the exact same environment using this mechanism.
>> 
>> I think we should have such a DecContainer for Guix programmers? 😄
>> 
>> -Yasu
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> Help-Guix mailing list
>> Help-Guix@gnu.org
>> https://lists.gnu.org/mailman/listinfo/help-guix
>> 
>> 
>> ------------------------------
>> 
>> End of Help-Guix Digest, Vol 92, Issue 9
>> ****************************************
> 
> -- 
> repositories: https://notabug.org/ZelphirKaltstahl
> 

Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

[wolf]

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

On 2023-07-12 10:22:33 +0900, Yasuaki Kudo wrote:
> Thank you for this link Zelphir!
> 
> While I don't know much about this, it smells like the restrictions are the same sort that Chrome and Firefox put as the proprietary surface layered on top of the respective copyleft foundation?
> 
> I tried the de-microsofted VSCodium when I used to run GuixOS (Now I am back to Ubuntu) but it didn't work well so I left it at that 😅
> 
> My gut feeling is that Guix will excel at as niche and very efficient software packaging system and the popularity and adoption could expand from there. 
> 
> So I thought VSCode DevContainer could be a very good place to start!  
> 
> An example use case I can think of is for GitHub Actions continuous integration.  It seems to me that local SSD caching (10GB) is almost instantaneous. We can cache the Guix build dependencies there.  
> 
> Then, it will create a Docker image as an artifact from the CI-run.  The image is as small as it can be because Guix only installs the necessary software.

Careful about this assumption, Guix-generated container images are pretty large
and include a lot of things you might not want in there (man, info pages, bash,
...).  I am not saying "do not use it", but if you try to convince people to use
Guix for container builds, size should not be your argument (especially since
Alpine exists as an alternative).

> 
> This will be very beneficial because the artifact (Docker images) uploads/downloads seem to very slow!
> 
> This way, we can gradually introduce Guix to development teams as niche software for specific cases?  (The guix docker images will work together with many other docker images created in conventional ways)
> 
> -Yasu
> 
> > On Jul 12, 2023, at 04:23, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
> > 
> > Hello Yasu,
> > 
> > There are some legal aspects about using the official "marketplace" from other than the official VSCode build: https://github.com/VSCodium/vscodium/blob/master/DOCS.md#extensions--marketplace at least according to the VSCodium linking to https://github.com/microsoft/vscode/issues/31168, wherein someone interpreted things: https://github.com/microsoft/vscode/issues/31168#issuecomment-1136375670.
> > 
> > Not sure this plays any role in your proposed process. It is something to keep in mind.
> > 
> > Regards,
> > Zelphir
> > 
> >> On 7/11/23 18:00, help-guix-request@gnu.org wrote:
> >> Send Help-Guix mailing list submissions to
> >>    help-guix@gnu.org
> >> 
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>    https://lists.gnu.org/mailman/listinfo/help-guix
> >> or, via email, send a message with subject or body 'help' to
> >>    help-guix-request@gnu.org
> >> 
> >> You can reach the person managing the list at
> >>    help-guix-owner@gnu.org
> >> 
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of Help-Guix digest..."
> >> 
> >> 
> >> Today's Topics:
> >> 
> >>    1. VSCode DevContainer for Guix? (Yasuaki Kudo)
> >> 
> >> 
> >> ----------------------------------------------------------------------
> >> 
> >> Message: 1
> >> Date: Tue, 11 Jul 2023 05:55:33 +0900
> >> From: Yasuaki Kudo <yasu@yasuaki.com>
> >> To: help-guix <help-guix@gnu.org>
> >> Subject: VSCode DevContainer for Guix?
> >> Message-ID: <BB9B5B1E-810C-4315-AD49-9FEC156F5E9E@yasuaki.com>
> >> Content-Type: text/plain; charset=utf-8
> >> 
> >> Hello!!
> >> 
> >> So I have just spent a month battling with Docker and VSCode for a project and became familiar with them.  Combining both, we can create a very pleasant and reproducible developer environment that everyone can copy.
> >> 
> >> DevContainer is like Screen/Tmux on steroids - the heavy lifting of compilation and running can be shifted to a Docker, a remote SSH session, or a combination of both, while the end-programmer can interact with the local VSCode IDE.  And the developer-facing computer can be any of the 3 - Linux, Windows or Macintosh (inclusive of Apple custom CPU)
> >> 
> >> A development team can share the exact same environment using this mechanism.
> >> 
> >> I think we should have such a DecContainer for Guix programmers? 😄
> >> 
> >> -Yasu
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> ------------------------------
> >> 
> >> Subject: Digest Footer
> >> 
> >> _______________________________________________
> >> Help-Guix mailing list
> >> Help-Guix@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/help-guix
> >> 
> >> 
> >> ------------------------------
> >> 
> >> End of Help-Guix Digest, Vol 92, Issue 9
> >> ****************************************
> > 
> > -- 
> > repositories: https://notabug.org/ZelphirKaltstahl
> > 
>

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

[Ekaitz Zarraga]

> Careful about this assumption, Guix-generated container images are pretty large
> and include a lot of things you might not want in there (man, info pages, bash,
> ...). I am not saying "do not use it", but if you try to convince people to use
> Guix for container builds, size should not be your argument (especially since
> Alpine exists as an alternative).

That is very true.
This week in System Crafters they have been workin on trying to reduce this. But I didn't have the time to watch the results deeply.
Be careful, youtube link:
https://www.youtube.com/watch?v=ItGRcOLT-BM

Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

[Yasuaki Kudo]

Thank you for this, yes, this is exactly the kind if idea I had in mind, although I was assuming that Guix docker would be super bare bones by almost default 😄

I think keeping the core of your software benefits the entire system, making it secure and keeping the cost down for storage, hosting and running.

So that's why I am interested 😄

-Yasu

> On Jul 12, 2023, at 20:27, Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
> 
> 
>> Careful about this assumption, Guix-generated container images are pretty large
>> and include a lot of things you might not want in there (man, info pages, bash,
>> ...). I am not saying "do not use it", but if you try to convince people to use
>> Guix for container builds, size should not be your argument (especially since
>> Alpine exists as an alternative).
> 
> That is very true.
> This week in System Crafters they have been workin on trying to reduce this. But I didn't have the time to watch the results deeply.
> Be careful, youtube link:
> https://www.youtube.com/watch?v=ItGRcOLT-BM

Re: VSCode DevContainer for Guix? (Yasuaki Kudo)

[Simon Tournier]

Hi,

On Wed, 12 Jul 2023 at 10:27, wolf <wolf@wolfsden.cz> wrote:

>> Then, it will create a Docker image as an artifact from the CI-run.
>> The image is as small as it can be because Guix only installs the
>> necessary software. 
>
> Careful about this assumption, Guix-generated container images are pretty large
> and include a lot of things you might not want in there (man, info pages, bash,
> ...).  I am not saying "do not use it", but if you try to convince people to use
> Guix for container builds, size should not be your argument (especially since
> Alpine exists as an alternative).

Yes, the images generated by Guix cannot considered as minimal. :-)

Aside bugs – see #63050 [a] for one example of such bug –, as I pointed
in [b],

        The tacit policy with Guix packages is that the packages are usually by
        default “feature maximalist” or specifically named « <foo>-minimal » …

        > Right, and reportedly, Alpine-based images for things like Python are
        > smaller than what we do.  There’s no cheating here: images are
        > self-contained.

        …contrary to Alpine where the packages are usually by default “feature
        minimalist” or specifically named « <foo>-<with-feature> ».

        Consider the package Emacs [1] and give a look at the recipe for the
        package named ’emacs’ [2].  Well, this Alpine package ’emacs’ looks like
        the Guix package named ’emacs-minimal’, and then Alpine provides these
        variants (subpackages):

            emacs-doc
            emacs-gtk3
            emacs-gtk3-nativecomp
            emacs-nox
            emacs-x11
            emacs-x11-nativecomp

        1: <https://pkgs.alpinelinux.org/package/edge/community/x86/emacs>
        2: <https://git.alpinelinux.org/aports/tree/community/emacs/APKBUILD>

a: https://issues.guix.gnu.org/issue/63050
b: https://yhetil.org/guix/87v8l1qy0j.fsf@gmail.com

Cheers,
simon