| Message ID | 871qlq89kz.fsf@ngraves.fr |
|---|---|
| Headers | show |
| Series | Juliahub import script. | expand |
Hi Nicolas, Sorry for the delay. (I was in holidays \o/ :-)) I am not able to apply the series. Could you rebase it or provide here by email the commit against which the series apply. Thanks in advance. On mer., 15 mars 2023 at 13:47, Nicolas Graves via Guix-patches via <guix-patches@gnu.org> wrote: > Took me quite more time than I would've liked, but I have a usable > juliahub scheme import script! Really cool! Thank you! > It seems there's still one edge case that isn't covered and revolves > around when Julia packagers don't properly tag their git repos (I've > only seen the case with SnoopPrecompile). There's the possibility to > rely on tree commit hashes from the General repository (since this is a > valid way to identify/store a git repo), but that needs some major > changes in the way latest-repository-commit works. Otherwise, it needs > to be done by hand. It might also not work for subpackages in > directories that are up-to-date on juliahub but not yet on github, I > haven't met this case yet. > > I'm sending a patch series in the coming minutes. Well, I have not read all series. :-) Cheers, simon
Hi! Nicolas Graves <ngraves@ngraves.fr> skribis: > Took me quite more time than I would've liked, but I have a usable > juliahub scheme import script! > > It seems there's still one edge case that isn't covered and revolves > around when Julia packagers don't properly tag their git repos (I've > only seen the case with SnoopPrecompile). There's the possibility to > rely on tree commit hashes from the General repository (since this is a > valid way to identify/store a git repo), but that needs some major > changes in the way latest-repository-commit works. Otherwise, it needs > to be done by hand. It might also not work for subpackages in > directories that are up-to-date on juliahub but not yet on github, I > haven't met this case yet. > > I'm sending a patch series in the coming minutes. > > It's detailed since I haven't swauased all commits, for readability, but > I can squash it further if necessary. I’ll let Simon comment on the actual code since I’m not a Julia person. :-) Some more general comments: • Please make sure to document it in ‘doc/guix.texi’ under “Invoking guix import”, following the same template as the others there. • Please write ‘tests/juliahub.scm’. I recommend the same strategy as ‘tests/cpan.scm’, which is to mock the upstream HTTP server. • Prefer (srfi srfi-41) over (ice-9 streams) (see rationale at <https://srfi.schemers.org/srfi-41/srfi-41.html>). • Prefer (srfi srfi-71) over (srfi srfi-11) for multiple-value bindings. Thanks, Ludo’.
Hello Nicolas & Simon! What should we do about this importer? Looks like useful code to me! Thanks, Ludo’. Ludovic Courtès <ludo@gnu.org> skribis: > Hi! > > Nicolas Graves <ngraves@ngraves.fr> skribis: > >> Took me quite more time than I would've liked, but I have a usable >> juliahub scheme import script! >> >> It seems there's still one edge case that isn't covered and revolves >> around when Julia packagers don't properly tag their git repos (I've >> only seen the case with SnoopPrecompile). There's the possibility to >> rely on tree commit hashes from the General repository (since this is a >> valid way to identify/store a git repo), but that needs some major >> changes in the way latest-repository-commit works. Otherwise, it needs >> to be done by hand. It might also not work for subpackages in >> directories that are up-to-date on juliahub but not yet on github, I >> haven't met this case yet. >> >> I'm sending a patch series in the coming minutes. >> >> It's detailed since I haven't swauased all commits, for readability, but >> I can squash it further if necessary. > > I’ll let Simon comment on the actual code since I’m not a Julia person. > :-) > > Some more general comments: > > • Please make sure to document it in ‘doc/guix.texi’ under “Invoking > guix import”, following the same template as the others there. > > • Please write ‘tests/juliahub.scm’. I recommend the same strategy as > ‘tests/cpan.scm’, which is to mock the upstream HTTP server. > > • Prefer (srfi srfi-41) over (ice-9 streams) (see rationale at > <https://srfi.schemers.org/srfi-41/srfi-41.html>). > > • Prefer (srfi srfi-71) over (srfi srfi-11) for multiple-value > bindings. > > Thanks, > Ludo’.
Hi Ludo,
Sorry for the delay, I was again in holidays. :-)
On Tue, 08 Aug 2023 at 17:24, Ludovic Courtès <ludo@gnu.org> wrote:
> What should we do about this importer? Looks like useful code to me!
Yeah, it looks nice. As I said [1], “I am not able to apply the
series.” And since the series is 21 patches, I have been lazy.
1: https://yhetil.org/guix/87v8i7k6uv.fsf@gmail.com
Cheers,
simon
Hello Nicolas, Simon Tournier <zimon.toutoune@gmail.com> writes: [...] > Yeah, it looks nice. As I said [1], “I am not able to apply the > series.” And since the series is 21 patches, I have been lazy. I just want to add that on 2023-09-13 Simon explained failed attempts to apply this patch series in a message to guix-devel [1] (starting from the string "I am not speaking on the vacuum of an hypothetical problem"). I quote some output Simon got: >> Using the usual “git am -3s” from Emacs Debbugs, then I get: >> >> --8<---------------cut here---------------start------------->8--- >> Applying: import: juliahub: first script draft. >> error: sha1 information is lacking or useless (guix/import/go.scm). >> error: could not build fake ancestor >> hint: Use 'git am --show-current-patch=diff' to see the failed patch >> Patch failed at 0001 import: juliahub: first script draft. >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am --abort". >> --8<---------------cut here---------------end--------------->8--- Please see the original message [1] for details. Sorry I can't help resolving this problem right now and/or send an updated patch series. Nicolas could you please try to apply it yourself to see if you are succeful and eventually send a V2 patch series? Thanks! Gio' [1] id:874jjzfhx0.fsf@gmail.com https://yhetil.org/guix/874jjzfhx0.fsf@gmail.com/
On 2023-09-15 11:45, Giovanni Biscuolo wrote: > Hello Nicolas, > > Simon Tournier <zimon.toutoune@gmail.com> writes: > > [...] > >> Yeah, it looks nice. As I said [1], “I am not able to apply the >> series.” And since the series is 21 patches, I have been lazy. > > I just want to add that on 2023-09-13 Simon explained failed attempts to > apply this patch series in a message to guix-devel [1] (starting from > the string "I am not speaking on the vacuum of an hypothetical > problem"). > > I quote some output Simon got: > >>> Using the usual “git am -3s” from Emacs Debbugs, then I get: >>> >>> --8<---------------cut here---------------start------------->8--- >>> Applying: import: juliahub: first script draft. >>> error: sha1 information is lacking or useless (guix/import/go.scm). >>> error: could not build fake ancestor >>> hint: Use 'git am --show-current-patch=diff' to see the failed patch >>> Patch failed at 0001 import: juliahub: first script draft. >>> When you have resolved this problem, run "git am --continue". >>> If you prefer to skip this patch, run "git am --skip" instead. >>> To restore the original branch and stop patching, run "git am --abort". >>> --8<---------------cut here---------------end--------------->8--- > > Please see the original message [1] for details. > > Sorry I can't help resolving this problem right now and/or send an > updated patch series. > > Nicolas could you please try to apply it yourself to see if you are > succeful and eventually send a V2 patch series? Hi Giovanni, Sorry for the lack of work to get this merged. I must still have this branch locally, I'll try to output a V2. The issue I had with the use is that my factorization of some functions broke the Go importer, so either I have to fix that or drop the factorization and duplicate the code in the juliahub importer. I'll try to work on that this weekend, thanks for asking. Nicolas > > Thanks! Gio' > > > [1] id:874jjzfhx0.fsf@gmail.com https://yhetil.org/guix/874jjzfhx0.fsf@gmail.com/
Hi Nicolas, On Fri, 15 Sept 2023 at 15:32, Nicolas Graves <ngraves@ngraves.fr> wrote: > Sorry for the lack of work to get this merged. I must still have this > branch locally, I'll try to output a V2. Oh, thank you. I am really sorry for the burden. > I'll try to work on that this weekend, thanks for asking. Previously, I have asked too and you have probably missed it. :-) And I was in the mood to go via some boring manual work this week. I am very happy if it can be avoided and you are able to find some v2. Have a nice week-end. Cheers, simon
On 2023-09-15 16:01, Simon Tournier wrote: > Hi Nicolas, > > On Fri, 15 Sept 2023 at 15:32, Nicolas Graves <ngraves@ngraves.fr> wrote: > >> Sorry for the lack of work to get this merged. I must still have this >> branch locally, I'll try to output a V2. > > Oh, thank you. I am really sorry for the burden. > >> I'll try to work on that this weekend, thanks for asking. > > Previously, I have asked too and you have probably missed it. :-) And > I was in the mood to go via some boring manual work this week. I am > very happy if it can be avoided and you are able to find some v2. > > Have a nice week-end. Couldn't find time this wkend, but it's on my backlog, I'll try to do that soon. > > Cheers, > simon
Hi Nicolas, On Mon, 18 Sep 2023 at 11:31, Nicolas Graves via Guix-patches via <guix-patches@gnu.org> wrote: > Couldn't find time this wkend, but it's on my backlog, I'll try to do > that soon. No worry. I did it manually. :-) I have sent v2 which is just your patches applied the top of 3d9ebc7b2ed24312fd6a0916c203f7b86d57753d. My plan is to give a look to the series this week. Cheers, simon
Hi Simon, Simon Tournier <zimon.toutoune@gmail.com> writes: [...] > No worry. I did it manually. :-) out of curiosity, what do you mean by "manually" please? I mean: ho did you got to apply the patches? I'm asking because it could be helpful to others > I have sent v2 which is just your patches applied the top of > 3d9ebc7b2ed24312fd6a0916c203f7b86d57753d. > > My plan is to give a look to the series this week. thank you! Happy hacking! Gio'
Hi, On Tue, 19 Sep 2023 at 08:23, Giovanni Biscuolo <g@xelera.eu> wrote: > out of curiosity, what do you mean by "manually" please? I mean: ho did > you got to apply the patches? I mean literally. ;-) Open the patch, read it and then open the file, modify it, commit. Repeat. Else, I just pipe the message with “git am -3s”. Cheers, simon
On 2023-09-18 20:06, Simon Tournier wrote: > Hi Nicolas, > > On Mon, 18 Sep 2023 at 11:31, Nicolas Graves via Guix-patches via <guix-patches@gnu.org> wrote: > >> Couldn't find time this wkend, but it's on my backlog, I'll try to do >> that soon. > > No worry. I did it manually. :-) > > I have sent v2 which is just your patches applied the top of > 3d9ebc7b2ed24312fd6a0916c203f7b86d57753d. > > My plan is to give a look to the series this week. Just note that in my experience, the juliahub importer worked quite well (there was sometimes errors, mainly annoying with recursive imports when the git repository didn't have any tag IIRC, not sure if I had fixed that or not). The other annoying thing was that the factorization broke the go importer IIRC. But these fixes shouldn't be too hard compared to the initial effort to make the importer. Thanks a lot and good luck, sorry, quite hard to find time recently. > Cheers, > simon
Hi, On Tue, 19 Sep 2023 at 08:51, Nicolas Graves via Guix-patches via <guix-patches@gnu.org> wrote: >> My plan is to give a look to the series this week. [...] > Thanks a lot and good luck, sorry, quite hard to find time recently. I pause a bit. If someone is motivated, feel free to pick it. Else I will resume when I will be able to dedicate some time for that. Cheers, simon