[GSOC 2020] Discussing GNU Guix project ideas?

[GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

Dear all,

My name is Leandro Doctors. I am seriously considering applying to
GSoC 2020 with GNU Guix.

I am interested in the Scheme-based ideas. (I have recently
rediscovered LISP, and I am a Clojure fan.) However, I haven't found
any indication on how to proceed in the Ideas page [1].

As per Pjotr Prins' suggestion, I subscribed to this list.

Could you please point me in the right direction? I mean, is there a
place where I should publish a draft to get feedback (like, a gist or
similar), or should I just send emails here?

Thank you in advance for your reply,
Leandro

[1] https://libreplanet.org/wiki/Group:Guix/GSoC-2020

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Ricardo Wurmus]

Hi Leandro,

> My name is Leandro Doctors. I am seriously considering applying to
> GSoC 2020 with GNU Guix.

Oh, that’s nice!

> I am interested in the Scheme-based ideas. (I have recently
> rediscovered LISP, and I am a Clojure fan.) However, I haven't found
> any indication on how to proceed in the Ideas page [1].

Is there any project in particular that you find interesting?

> Could you please point me in the right direction? I mean, is there a
> place where I should publish a draft to get feedback (like, a gist or
> similar), or should I just send emails here?

A draft for what exactly?  Usually we just discuss things right here on
the mailing list.  The mentors of the proposed projects are also reading
this list.

--
Ricardo

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 05:16, Ricardo Wurmus <rekado@elephly.net> wrote:
> Usually we just discuss things right here on the mailing list.

That is a great starting pointer, Ricardo. Thanks! :-)


> A draft for what exactly?

Well, as I said before, I have only started reading the Ideas page.
All I know right now is that I would like to work on a Scheme-related
project :-)

I will clone Guix's repo, read the code and try building it, and get
back with more specific details, if that's OK with you.

Best,
Leandro

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 08:52, Leandro Doctors <ldoctors@gmail.com> wrote:
> I will clone Guix's repo, read the code and try building it, and get
> back with more specific details, if that's OK with you.

I checked the Guix group page [1], and found several repos...

[1] https://savannah.gnu.org/git/?group=guix


Could anyone please advise me which one(s) to clone first in to get started?


Best,
Leandro

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[zimoun]

Hi Leandro,

On Thu, 27 Feb 2020 at 12:54, Leandro Doctors <ldoctors@gmail.com> wrote:

> I will clone Guix's repo, read the code and try building it, and get
> back with more specific details, if that's OK with you.

Are you using Guix yet?

If no, the first easy step is to install the "package manager". It
works on any recent Linux distro and it will not interfere with it.
Using the shell script helper, it is quick; and nothing to do. See:
https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
from the note in the manual
http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation

If yes, the easy way to start is:

git clone https://git.savannah.gnu.org/git/guix.git
cd guix
guix environment guix
./bootstrap
./configure --localstatedir=/var/
make

then you can tweak any scheme file and recompile with make. And to use
this checkout version, you can just run the ./pre-env-inst hook.

 ./pre-inst-env guix help


Hope that helps.

All the best,
simon

[GSOC 2020] Improving the manual?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 11:44, zimoun <zimon.toutoune@gmail.com> wrote:
> Are you using Guix yet?
>
> If no, the first easy step is to install the "package manager".
[...]

Thanks for the instructions, Simon!
I have just successfully installed Guix :-)


> If yes, the easy way to start is:
> git clone https://git.savannah.gnu.org/git/guix.git

> from the note in the manual
> http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation

While cloning the guix repo above, I found a minor omission in the
documentation. However, I could not find its repo in the list from the
Savannah group [1] in order to fix it and create a pull/merge request
or patch...

[1]: https://savannah.gnu.org/git/?group=guix


Could anyone please point me to in the manual repo? Besides... Where
could I find documentation on the workflow for working on the manual
proper so I can actually send my patch? I could not find it in the
online manual version [2]...

[2]: https://guix.gnu.org/manual/en/


Best,
Leandro

Re: [GSOC 2020] Improving the manual?

[zimoun]

On Fri, 28 Feb 2020 at 01:22, Leandro Doctors <ldoctors@gmail.com> wrote:

> > If yes, the easy way to start is:
> > git clone https://git.savannah.gnu.org/git/guix.git
>
> > from the note in the manual
> > http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
>
> While cloning the guix repo above, I found a minor omission in the
> documentation. However, I could not find its repo in the list from the
> Savannah group [1] in order to fix it and create a pull/merge request
> or patch...
>
> [1]: https://savannah.gnu.org/git/?group=guix

Hum? I am not sure to understand what you are asking.

The source of the manual lives under doc/ of what is cloned above; i.e.,

https://git.savannah.gnu.org/cgit/guix.git/tree/doc


The submission of patches is done via "git format-patch" and by email
via "git send-email --to=guix-patches@gnu.org" (package
git:send-email).


> Could anyone please point me to in the manual repo? Besides... Where
> could I find documentation on the workflow for working on the manual
> proper so I can actually send my patch? I could not find it in the
> online manual version [2]...
>
> [2]: https://guix.gnu.org/manual/en/

Maybe you could be interested by this section of the manual:

https://guix.gnu.org/manual/devel/en/guix.html#Contributing


Hope that helps.

All the best,
simon

Re: [GSOC 2020] Improving the manual?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 21:39, sirgazil <sirgazil@zoho.com> wrote:
> On Thu, 27 Feb 2020 at 21:37, zimoun <zimon.toutoune@gmail.com> wrote:

>> The source of the manual lives under doc/ of what is cloned above;

> The documentation is in the same repository of the guix source code (see the doc directory).

Thanks, guys. I see it now. I had missed it.

And thanks for the pointer to the "contributing" section. Even thought
I had skimmed it, as I could not find the doc sources, I thought the
process for the docs was different.

Best,
Leandro

Re: [GSOC 2020] Improving the manual?

[sirgazil]

 ---- On Thu, 27 Feb 2020 19:22:17 -0500 Leandro Doctors <ldoctors@gmail.com> wrote ----
 > On Thu, 27 Feb 2020 at 11:44, zimoun <zimon.toutoune@gmail.com> wrote:
 > > Are you using Guix yet?
 > >
 > > If no, the first easy step is to install the "package manager".
 > [...]
 > 
 > Thanks for the instructions, Simon!
 > I have just successfully installed Guix :-)
 > 
 > 
 > > If yes, the easy way to start is:
 > > git clone https://git.savannah.gnu.org/git/guix.git
 > 
 > > from the note in the manual
 > > http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
 > 
 > While cloning the guix repo above, I found a minor omission in the
 > documentation. However, I could not find its repo in the list from the
 > Savannah group [1] in order to fix it and create a pull/merge request
 > or patch...
 > 
 > [1]: https://savannah.gnu.org/git/?group=guix
 > 
 > 
 > Could anyone please point me to in the manual repo?

The documentation is in the same repository of the guix source code (see the doc directory).

https://git.savannah.gnu.org/cgit/guix.git/tree/doc


 > Besides... Where
 > could I find documentation on the workflow for working on the manual
 > proper so I can actually send my patch? I could not find it in the
 > online manual version [2]...

I don't think there are specific steps to work in the manual, but a general section on Contributing (see https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing).

I guess you could create a patch and send it to guix-patches as decribed in https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches.

[GSOC 2020] Idea: Guile based build-tool

[Leandro Doctors]

Hi, all,

I am starting to do some research on this idea.

Even though I haven't checked Guix's code yet (I plan to flickr it in
the upcoming days), I am thinking on getting some inspiration from the
architecture of similar Clojure-focused tools (which, as I stated
earlier, is what I know).

I know about three such tools: leiningen[1], boot[2], and clojure.deps[3].

I plan to flickr over their code, and see what architectural decitions
could be proposed.
What do you think about this?

Best,
Leandro

[1] leiningen: https://github.com/technomancy/leiningen
[2] boot: https://github.com/boot-clj/boot
[3] clojure.deps: https://github.com/clojure/tools.deps.alpha

Re: [GSOC 2020] Idea: Guile based build-tool

[Christopher Lemmer Webber]

There have been some conversations about using Guix's tooling as a build
tool in the past.

Personally, what I would prefer to see is a Guile-based build tool that
is standalone; an alternative for autotools basically.  That then could
be used *in combination with* Guix quite nicely... use the Guile-based
build tool for describing how to build your packages, use "guix
environment" to pull in all the dependencies and create the dev
environment, and of course this tool would then be used for package
definitions too.

However I think this is not a small task, and would take someone who is
willing to do a fair amount of research, or is already familiar with the
problem domain.  It may be hard to finish in a single summer.


Leandro Doctors writes:

> Hi, all,
>
> I am starting to do some research on this idea.
>
> Even though I haven't checked Guix's code yet (I plan to flickr it in
> the upcoming days), I am thinking on getting some inspiration from the
> architecture of similar Clojure-focused tools (which, as I stated
> earlier, is what I know).
>
> I know about three such tools: leiningen[1], boot[2], and clojure.deps[3].
>
> I plan to flickr over their code, and see what architectural decitions
> could be proposed.
> What do you think about this?
>
> Best,
> Leandro
>
> [1] leiningen: https://github.com/technomancy/leiningen
> [2] boot: https://github.com/boot-clj/boot
> [3] clojure.deps: https://github.com/clojure/tools.deps.alpha

Re: [GSOC 2020] Idea: Guile based build-tool

[zimoun]

Dear,

Perhaps, some inspiration about build systems in this paper [1] by Haskellers.

[1] https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf


All the best,
simon

Re: [GSOC 2020] Idea: Guile based build-tool

[Leandro Doctors]

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

Thanks for the link, Simon!
--Leandro

On Mon, 2 Mar 2020, 07:03 zimoun, <zimon.toutoune@gmail.com> wrote:

> Dear,
>
> Perhaps, some inspiration about build systems in this paper [1] by
> Haskellers.
>
> [1]
> https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf
>
>
> All the best,
> simon
>

[-- Attachment #2: Type: text/html, Size: 809 bytes --]

[GSOC 2020] Guix Deploy, round 2!

[Christopher Lemmer Webber]

Hello,

I'd be interested in doing a round 2 of mentoring for Guix Deploy.
The previous student (Jakob L. Kreuze) will not be a GSoC student this
year but is willing to co-mentor.  (Maybe David Thompson is as well but
I won't speak for him since we haven't discussed it yet.)

I don't know what the situation with Outreachy slots are, but I'd also
be happy to mentor this for there as well, obviously.

I think there's probably more that can be done to improve environments.
This includes initial bootstrapping of environments, making more
environments available, etc.

Let me also put out a goal for the Guix community: I think we'll see
Guix Deploy as a success if a bunch of us can switch over to using it on
our own servers (that includes me).  To that end, I'd love to know, how
many people are doing so, or have attempted to do so?  What features
would you like/need?

 - Chris

Re: [GSOC 2020] Guix Deploy, round 2!

[Gábor Boskovits]

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

Hello Chris,

Christopher Lemmer Webber <cwebber@dustycloud.org> ezt írta (időpont: 2020.
febr. 29., Szo 17:55):

> Hello,
>
> I'd be interested in doing a round 2 of mentoring for Guix Deploy.
> The previous student (Jakob L. Kreuze) will not be a GSoC student this
> year but is willing to co-mentor.  (Maybe David Thompson is as well but
> I won't speak for him since we haven't discussed it yet.)
>

Wonderful idea, please add it to the GSoC 2020 ideas page if you haven't
done so.


> I don't know what the situation with Outreachy slots are, but I'd also
> be happy to mentor this for there as well, obviously.
>

The proposal deadline for this round has passed, so we can't do that right
now. If we still have work to do in this area ( I believe we will) when the
next round comes around, I will be happy to help in forming the proposal. I
will soon publish a blog post with the relevant deadlines for both program.


> I think there's probably more that can be done to improve environments.
> This includes initial bootstrapping of environments, making more
> environments available, etc.
>
> Let me also put out a goal for the Guix community: I think we'll see
> Guix Deploy as a success if a bunch of us can switch over to using it on
> our own servers (that includes me).  To that end, I'd love to know, how
> many people are doing so, or have attempted to do so?  What features
> would you like/need?
>

I believe this is a great initiative. Thanks for bringing this up.

>
>  - Chris
>

Best regards,
g_bor

>
>

[-- Attachment #2: Type: text/html, Size: 2839 bytes --]

Re: [GSOC 2020] Guix Deploy, round 2!

[Ludovic Courtès]

Hi Chris!

Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:

> Let me also put out a goal for the Guix community: I think we'll see
> Guix Deploy as a success if a bunch of us can switch over to using it on
> our own servers (that includes me).  To that end, I'd love to know, how
> many people are doing so, or have attempted to do so?  What features
> would you like/need?

We’re using it for the build farm, and I’m also using it for a couple of
single servers.  It’s great!  :-)

What I miss the most, especially on the build farm, is the ability to
tell ‘guix deploy’ which services to restart upon completion.
Currently, like ‘guix system reconfigure’, it conservatively doesn’t
restart any running services.  However, often, you’d like it to run
“herd restart X” upon completion.

Another thing discussed at the Guix Days, but more relevant to more
advanced use cases, is the ability to define “roles”: often you’d rather
want to think in terms of the services machines offer and abstract over
the actual machines.

Ludo’.

Re: [GSOC 2020] Guix Deploy, round 2!

[Gábor Boskovits]

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

Hello,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2020. márc. 8., Vas
23:10):

> Hi Chris!
>
> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>
> > Let me also put out a goal for the Guix community: I think we'll see
> > Guix Deploy as a success if a bunch of us can switch over to using it on
> > our own servers (that includes me).  To that end, I'd love to know, how
> > many people are doing so, or have attempted to do so?  What features
> > would you like/need?
>
> We’re using it for the build farm, and I’m also using it for a couple of
> single servers.  It’s great!  :-)
>
> What I miss the most, especially on the build farm, is the ability to
> tell ‘guix deploy’ which services to restart upon completion.
> Currently, like ‘guix system reconfigure’, it conservatively doesn’t
> restart any running services.  However, often, you’d like it to run
> “herd restart X” upon completion.
>
> Another thing discussed at the Guix Days, but more relevant to more
> advanced use cases, is the ability to define “roles”: often you’d rather
> want to think in terms of the services machines offer and abstract over
> the actual machines.
>

These are both great ideas. It would be also nice to access these in a
single machine setup. I don't know where to implement this, it might make
sense to add these to the common part of deploy and reconfigure. IIRC we
also discussed the idea of a local deployer to be able handle the deploy
node the same way as the rest. Regarding the roles thing it would be nice
to get a discussion going regarding the interface, so that we have an idea
how it should look like. Wdyt?

>
> Ludo’.
>
Best regards,
g_bor

>
>

[-- Attachment #2: Type: text/html, Size: 2593 bytes --]

Re: [GSOC 2020] Guix Deploy, round 2!

[Ludovic Courtès]

Hi!

Gábor Boskovits <boskovits@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2020. márc. 8., Vas
> 23:10):

[...]

>> What I miss the most, especially on the build farm, is the ability to
>> tell ‘guix deploy’ which services to restart upon completion.
>> Currently, like ‘guix system reconfigure’, it conservatively doesn’t
>> restart any running services.  However, often, you’d like it to run
>> “herd restart X” upon completion.
>>
>> Another thing discussed at the Guix Days, but more relevant to more
>> advanced use cases, is the ability to define “roles”: often you’d rather
>> want to think in terms of the services machines offer and abstract over
>> the actual machines.
>>
>
> These are both great ideas. It would be also nice to access these in a
> single machine setup. I don't know where to implement this, it might make
> sense to add these to the common part of deploy and reconfigure. IIRC we
> also discussed the idea of a local deployer to be able handle the deploy
> node the same way as the rest.

If you talking about the first point above, I think it’s not that
difficult.  As I see it, we could provide a command-line option and/or a
<machine> option (?) specifying which services should be restarted right
away.  Restarting can be implemented as in (guix scripts system
reconfigure).

> Regarding the roles thing it would be nice to get a discussion going
> regarding the interface, so that we have an idea how it should look
> like. Wdyt?

Yes, that would be nice!  There were good ideas discussed at the Guix
Days and knowledgeable people, but I can’t see the notes at
<https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2020>
and I’m not sure who was involved.  There was probably Chris Marusich,
who else?  People, please step up!  :-)

Ludo’.

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[zimoun]

Dear Leandro,

On Wed, 26 Feb 2020 at 23:42, Leandro Doctors <ldoctors@gmail.com> wrote:

> I am interested in the Scheme-based ideas. (I have recently
> rediscovered LISP, and I am a Clojure fan.) However, I haven't found
> any indication on how to proceed in the Ideas page [1].

Elsewhere, you have been discussing a proposal of about "Guile build
tool"; which IMHO a large and hard task.

Based on your interests (Clojure, Leiningen, etc.), you should
consider something around a Clojure "importer". (Note that I am
ignorant about the Java ecosystem.)

Currently, it is possible to import Python packages from PyPI, or
Haskell packages from Hackage, or etc. see [1] and something about
Clojure seems missing. I am quoting Ludo from [2]:

--8<---------------cut here---------------start------------->8---
Now we should keep in touch with the Clojure folks to work on an
importer (I learned about “tools.deps”) and to get Clojupyter packaged…
--8<---------------cut here---------------end--------------->8---

and then Jupyter is a "poor-man web-browser" version of Org-mode (very
opinionated! ;-)) and Clojupyter [3] is one of its kernel.


[1] https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-import.html
[2] https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00189.html
[3] https://github.com/clojupyter/clojupyter


Well, hope that helps as feedback.

Thanks,
simon

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

On Tue, 3 Mar 2020 at 19:32, zimoun <zimon.toutoune@gmail.com> wrote:
> Based on your interests (Clojure, Leiningen, etc.), you should
> consider something around a Clojure "importer". (Note that I am
> ignorant about the Java ecosystem.)

Thanks for the idea, Simon!


> Currently, it is possible to import Python packages from PyPI, or
> Haskell packages from Hackage, or etc. see [1] and something about
> Clojure seems missing. I am quoting Ludo from [2]:

Thanks for the pointers!
I will check these projects and let you know.


On another side, I will be offline for a fer days, so I expect to
start working on my proposal draft from March 16th onwards.
Would it be OK if I publish a project draft on
GoogleDocs/GitHub/GitLab in (let's say) MarkDown by March 20th, so
people can easily comment on it? I think getting feedback on a
document via email may be quite difficult...
Please, state your preference.

Best,
Leandro

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Gábor Boskovits]

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

Hello Leandro,

Leandro Doctors <ldoctors@gmail.com> ezt írta (időpont: 2020. márc. 3., Ke
23:45):

> On Tue, 3 Mar 2020 at 19:32, zimoun <zimon.toutoune@gmail.com> wrote:
> > Based on your interests (Clojure, Leiningen, etc.), you should
> > consider something around a Clojure "importer". (Note that I am
> > ignorant about the Java ecosystem.)
>
> Thanks for the idea, Simon!
>
>
> > Currently, it is possible to import Python packages from PyPI, or
> > Haskell packages from Hackage, or etc. see [1] and something about
> > Clojure seems missing. I am quoting Ludo from [2]:
>
> Thanks for the pointers!
> I will check these projects and let you know.
>
>
> On another side, I will be offline for a fer days, so I expect to
> start working on my proposal draft from March 16th onwards.
> Would it be OK if I publish a project draft on
> GoogleDocs/GitHub/GitLab in (let's say) MarkDown by March 20th, so
> people can easily comment on it? I think getting feedback on a
> document via email may be quite difficult...
> Please, state your preference.
>

Another option would be to add it to the ideas page in a comment. When it
is ready, it would be easy to publish it by uncommenting. That way the
ideas would stay om the same place.

Best regards,
g_bor

>
> Best,
> Leandro
>
>

[-- Attachment #2: Type: text/html, Size: 2043 bytes --]