Re: guix graph build phases

[jgart]

On Wed, 23 Nov 2022 01:09:43 -0600 jgart  wrote:
> On Wed, 23 Nov 2022 07:12:55 +0100 Julien Lepiller  wrote:

> %% python-build-system phases
> flowchart TB
> unpack --> 
> ensure-no-mtimes-pre-1980 -->
> enable-bytecode-determinism --> 
> ensure-no-cythonized-files --> 
> build --> 
> install -->
> add-install-to-pythonpath --> 
> add-install-to-path -->
> wrap --> 
> check -->
> sanity-check --> 
> rename-pth-file -->
> strip
> 

The above is the unmodified python-build-system phases but our idea here
is to generate them for each package and to account for changes made by
the modify-phases macro?

Re: guix graph build phases

[jgart]

On Wed, 23 Nov 2022 01:09:43 -0600 jgart  wrote:

oops ignore the typos here:

> :build -->;
> :install -->;
> :add-install-to-pythonpath;
> :add-install-to-path;
> :wrap -->;
> :check -->;

Re: guix graph build phases

[jgart]

On Wed, 23 Nov 2022 07:12:55 +0100 Julien Lepiller  wrote:
> I don't get why you want a picture. Could you share an example of what it 
> would look like?

I was just thinking of something like a flowchart for the build phases.

For example, python-build-system's phases as a flowchart in mermaidjs:

%% python-build-system phases
flowchart TB
unpack --> 
ensure-no-mtimes-pre-1980 -->
enable-bytecode-determinism --> 
ensure-no-cythonized-files --> 
build --> 
install -->
add-install-to-pythonpath --> 
add-install-to-path -->
wrap --> 
check -->
sanity-check --> 
rename-pth-file -->
strip

Here's the rendered mermaid flowchart:

https://kroki.io/mermaid/svg/eNptjz0OwjAMhfeeIgujJdhgYeAMXMBNjGKRP8WuqnJ6SloRCeHt2Z_t9w4HUxb1OcE4cXAgiyhFUzwKyfAIebYeq5r7bTBrTamgfRqAq2makkyVIGWIypEEyqpOl_Pxg-wEjoFgXJRsdgSOlGrkxBL_nbHNDL_IwYMDSWeavy45iWII3z_oHOw90AxbqILq-8ovsg_bbK5YOmk9bSmbEkysC3ybG1PXZJGgqG9OO62VyxteU2aW

The above diagram can easily be rewritten in plantuml and plantuml supports 
ascii diagrams also but ymmv:

https://www.planttext.com/api/plantuml/svg/RL0x2iCm3DrrYbn0q6vj0YK7wUBOAX6nPMChbFJqTPmiXMxl8_6UD1OrMTVW0PJLKvSsdQFWjB9tMBQY5Bgd0BGvW7wLPEmoG4zIrame4ODoe8AfiklzTccUcJpXj2dPw0WTAUN0mYNyRDeMnXzo-69FfPejk4DyLCnIKxq_cN4EJmKrub4q6Pt_U8VwpYQTotOckvou667Ti4cLvjes42QTMubzG3EdORyv9e2HnDK7VG40

@startuml
title python-build-system \n
start
:unpack;
:ensure-no-mtimes-pre-1980;
:enable-bytecode-determinism;
:ensure-no-cythonized-files;
:build -->;
:install -->;
:add-install-to-pythonpath;
:add-install-to-path;
:wrap -->;
:check -->;
:sanity-check;
:rename-pth-file;
:strip;
stop
@enduml

Where you thinking of capturing different information about the phases?

Re: guix graph build phases

[Julien Lepiller]

I don't get why you want a picture. Could you share an example of what it would 
look like?

Le 22 novembre 2022 23:43:19 GMT+01:00, jgart  a écrit :
>On Tue, 22 Nov 2022 23:12:16 +0100 Julien Lepiller  wrote:
>> The graph will always be flat, since it's a list, so graphviz would be a bit 
>> overkill :). Being able to list phases could still be cool :)
>
>How about with the plantuml that have packaged?

Re: issue tracking in git

[Pjotr Prins]

On Tue, Nov 22, 2022 at 06:57:59PM +0100, Giovanni Biscuolo wrote:
> Hello Pjotr
> 
> Giovanni Biscuolo  writes:
> 
> [...]
> 
> > As a new initiative we are discussing/designing a gemini + git issue
> > tracker.
> 
> please are there updates about this initiative?

Yeah, issue tracker lives here: 

=> https://issues.genenetwork.org/

The actual issues are in gemini format and can be served with a gemini
server. The HTML parser+renderer is written in Guile by Arun

=> https://git.systemreboot.net/tissue

Pj.

Re: guix graph build phases

[jgart]

On Tue, 22 Nov 2022 23:12:16 +0100 Julien Lepiller  wrote:
> The graph will always be flat, since it's a list, so graphviz would be a bit 
> overkill :). Being able to list phases could still be cool :)

How about with the plantuml that have packaged?

Re: guix graph build phases

[Julien Lepiller]

The graph will always be flat, since it's a list, so graphviz would be a bit 
overkill :). Being able to list phases could still be cool :)

Le 22 novembre 2022 22:32:54 GMT+01:00, jgart  a écrit :
>hi,
>
>`guix graph --phases` shows the order of phases for a particular package
>and any custom phases that were introduced, deleted, replaced, etc. with
>graphviz
>
>wdyt
>
>

Re: guix graph build phases

[jgart]

On Tue, 22 Nov 2022 15:32:54 -0600 jgart  wrote:
> wdyt

or maybe it should be:

guix build gnome-recipes --graph-phases

guix graph build phases

[jgart]

hi,

`guix graph --phases` shows the order of phases for a particular package
and any custom phases that were introduced, deleted, replaced, etc. with
graphviz

wdyt

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[Phil]

Hi,

Wojtek Kosior via Development of GNU Guix and the GNU System distribution. 
writes:

> Hi,
>
> I just want to add my 2 cents :)

Just to add mine too - libgit2 behaves differently to command-line git
in ways which can make guix do unexpected things when caching clones in
certain cases.  This has resulted in some hard to diagnose issues with
using guix to build PRs for example.

In particular we were forced to make this change to our local guix build
to ensure that guix behaved inline with git:
https://github.com/guix-mirror/guix/commit/473954dd92bbb84693b6fa3f007752eb53c804db

An explanation of why, was raised with libgit2:
https://github.com/libgit2/libgit2/issues/6183

The original guix-devel discussion here:
https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00021.html

This particular issue is somewhat niche - but it demonstrates well the
danger of assuming the libgit2 and git behave in the same way!

This makes me a bit wary of using libgit2 now.

Cheers,
Phil.

Re: Permanent URL for GUIX packages

[Development of GNU Guix and the GNU System distribution.]

Hello,that solves it for my project, thank you.On Nov 19, 2022, at 11:36, Luis Felipe  wrote:Hi Sunshine,
On Thursday, November 3rd, 2022 at 15:50, Sunshine via "Development of GNU Guix and the GNU System distribution."  wrote:

Hello,I'd like to link guix.gnu.org/packages/monolith-2.6.1/ from my project's README file (https://github.com/Y2Z/monolith), but due to the version string being part of the URL, I can't easily do that, would have to change the link for every new release.You can link to https://packages.guix.gnu.org/packages/monolith/ now.


publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: Binary data


signature.asc
Description: Binary data

Re: issue tracking in git

[Giovanni Biscuolo]

Hello Pjotr

Giovanni Biscuolo  writes:

[...]

> As a new initiative we are discussing/designing a gemini + git issue
> tracker.

please are there updates about this initiative?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[Development of GNU Guix and the GNU System distribution.]

Hi,

I just want to add my 2 cents :)

Another issue with libgit2 is that is gives a very misleading error
report when trying to http-clone a repo that only support the old
"dumb" git protocol (as opposed to the newer "smart" one). More details
here[1].

Missing support for that dumb protocol is probably not that big issue
in practice. The misleading error Guix presents to the users trying to
access some poor git repo is :/

Wojtek

[1] https://issues.guix.gnu.org/58555


-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #18: blessed Józef Kowalski
Poznaj świętych krakowskich!  #18: błogosławiony Józef Kowalski
https://pl.wikipedia.org/wiki/Józef_Kowalski_(duchowny)
-- (sig_end)


On Tue, 22 Nov 2022 11:49:26 -0500
"Philip McGrath"  wrote:

> Hi,
> 
> On Tue, Nov 22, 2022, at 10:39 AM, zimoun wrote:
> > Hi,
> >
> > On Mon, 21 Nov 2022 at 21:21, Maxim Cournoyer  
> > wrote:
> >  
> >> Given that:
> >>
> >> * the git CLI doesn't suffer from such poor performance;
> >> * This kind of performance problem has been known for years in libgit2
> >>   [0] with no fix in sight;
> >> * other projects such as Cargo support using the git CLI and that
> >>   projects are using it for that reason [1];  
> >
> > And I would add the lack of «Support for shallow repositories» [1].
> >
> > 1: 
> >  
> 
> >
> > PS: For the record, Software Heritage, which ingests *a lot* of Git
> > repositories, relies on Dulwhich [2] (pure Python implementation), IIUC.
> >
> > 2:   
> 
> Along those lines, there’s an implementation of clone/checkout in pure Racket 
> (for the package manager) that could probably be ported to Guile relatively 
> easily. I’d expect libgit2 to be faster for the things that it supports, but 
> the Racket implementation does support shallow checkout, so it might pay off 
> if that skips a lot of work.
> 
> Code: 
> https://github.com/racket/racket/blob/master/racket/collects/net/git-checkout.rkt
> Docs: https://docs.racket-lang.org/net/git-checkout.html
> 
> (More broadly, I haven’t investigated performance issues, but my basic 
> inclination would be toward improving libgit2 over running the git 
> executable.)
> 
> -Philip
> 




pgpALO0OTtztG.pgp
Description: OpenPGP digital signature

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[Philip McGrath]

Hi,

On Tue, Nov 22, 2022, at 10:39 AM, zimoun wrote:
> Hi,
>
> On Mon, 21 Nov 2022 at 21:21, Maxim Cournoyer  
> wrote:
>
>> Given that:
>>
>> * the git CLI doesn't suffer from such poor performance;
>> * This kind of performance problem has been known for years in libgit2
>>   [0] with no fix in sight;
>> * other projects such as Cargo support using the git CLI and that
>>   projects are using it for that reason [1];
>
> And I would add the lack of «Support for shallow repositories» [1].
>
> 1: 
>

>
> PS: For the record, Software Heritage, which ingests *a lot* of Git
> repositories, relies on Dulwhich [2] (pure Python implementation), IIUC.
>
> 2: 

Along those lines, there’s an implementation of clone/checkout in pure Racket 
(for the package manager) that could probably be ported to Guile relatively 
easily. I’d expect libgit2 to be faster for the things that it supports, but 
the Racket implementation does support shallow checkout, so it might pay off if 
that skips a lot of work.

Code: 
https://github.com/racket/racket/blob/master/racket/collects/net/git-checkout.rkt
Docs: https://docs.racket-lang.org/net/git-checkout.html

(More broadly, I haven’t investigated performance issues, but my basic 
inclination would be toward improving libgit2 over running the git executable.)

-Philip

Re: Layout of ‘define-configuration’ records

[zimoun]

Hi Maxim,

On Mon, 21 Nov 2022 at 16:00, Maxim Cournoyer  wrote:

> That sounds very appropriate indeed.  I guess we could send
> announcements on API breaking changes to both places.  I suppose not
> many people are registered to 'info-guix' (I wasn't myself until
> recently ^^').

Well, more is better here, no? :-)


> I guess that's a question of how disruptive the API change is, but it'd
> be convenient if it was 2 weeks to match the time the change might
> appear on guix-patches un-reviewed.

Well, the process for API change could be:

 1. + submit to guix-patches,
+ in the same time, announce to guix-devel; so people not subscribed to
  guix-patches can chime.
 2. + after 2 weeks, or consensus, merge the change,
+ in the same time, announce to guix-devel, info-guix and --news.

There is no extra burden and it smooths the change for many users, IMHO.

WDYT?

Cheers,
simon

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[zimoun]

Hi,

On Mon, 21 Nov 2022 at 21:21, Maxim Cournoyer  wrote:

> Given that:
>
> * the git CLI doesn't suffer from such poor performance;
> * This kind of performance problem has been known for years in libgit2
>   [0] with no fix in sight;
> * other projects such as Cargo support using the git CLI and that
>   projects are using it for that reason [1];

And I would add the lack of «Support for shallow repositories» [1].

1: 


> Would it make sense to switch to use the git command directly instead of
> calling into this libgit2 C library that ends up being slower?  It would
> provide a hefty speed-up when using 'guix refresh' or building new
> packages fetched from git without substitutes, or using 'git-checkout',
> etc.

Well, the question is about the closure and the bootstrap.

For instance,

--8<---cut here---start->8---
$ guix size guix | grep 'total:'
total: 629.5 MiB

$ guix size guix git-minimal | grep 'total:'
total: 671.0 MiB
--8<---cut here---end--->8---

which is not nothing but not so worse neither.  However, it would
require a fine scrutinizing about what would be added as dependencies.

The proposal is to fully drop ’guile-git’ and instead run ’(invoke "git"
)’ as in the module ’(guix build git)’, right?

Cheers,
simon

PS: For the record, Software Heritage, which ingests *a lot* of Git
repositories, relies on Dulwhich [2] (pure Python implementation), IIUC.

2: 

Remove lash

[Ricardo Wurmus]

Hi Guix,

on a modern Guix System with Gnome we’re pulling in Python 2.  That’s
because gtk uses lash, and lash (last commit was 14 years ago) comes
with Python bindings — for Python 2.

I’d like to propose one of the following steps:

- remove lash completely
- build lash without Python bindings, removing python2
- remove lash from fluidsynth, thereby removing it from the gtk closure

What do you think?

-- 
Ricardo

Re: [Guix Website] A Search Page for Packages

[Christopher Baines]

zimoun  writes:

> Hi Chris,
>
> On Mon, 21 Nov 2022 at 08:57, Christopher Baines  wrote:
>> zimoun  writes:
>>
>>> On Sat, 19 Nov 2022 at 10:51, Christopher Baines  wrote:
>>>
 It's really nice to have multiple things now (packages.guix.gnu.org,
 qa.guix.gnu.org, bordeaux.guix.gnu.org, ...) that are made possible by
 the Guix Data Service!
>>>
>>> Chris, what do you mean by «that are made possible by the Guix Data
>>> Service»?
>>
>> Only that the things I mention are making use of the Guix Data Service
>> to provide and query data.
>
> Just to be sure, by Guix Data Service, do you mean the code
> https://git.savannah.gnu.org/git/guix/data-service.git?  Or do you mean
> a generic name for all the services as qa.guix, bordeaux.guix,
> packages.guix or even issues.guix, logs.guix?

The former, the software with this source
https://git.savannah.gnu.org/git/guix/data-service.git


signature.asc
Description: PGP signature