[PATCH] Don't fix git executable location during Elixir build

  • Open
  • quality assurance status badge
Details
4 participants
  • Cees de Groot
  • Ludovic Courtès
  • Maxime Devos
  • Tobias Geerinckx-Rice
Owner
unassigned
Submitted by
Cees de Groot
Severity
normal
C
C
Cees de Groot wrote on 8 Mar 2022 21:52
(name . guix-patches@gnu.org)(address . guix-patches@gnu.org)
vJt9-EGxCcqYcRJpPwLXHo3DPOa8pdhHUN3rrKNuV7BI-evzYt_zYqj_XgYNdYE5Xv5OOf1U4fIsOPa0lBOWSh5fqKBrxxoeF1w3PkEAKiA=@evrl.com
The removed code below affected two locations where Elixir uses Git:

* At build-time, Git is used to see if the build is inside a Git repo and if so, git info
is added to the build information that Elixir returns with `System.build_info()`. The code
uses PATH + `git` so the Git version from the inputs is used which is just fine.
* At run-time, Git is used by Mix if, and only if, there are any Git-based dependencies. This
is not the normal case, and in that sense Git is an optional dependency of Elixir - most
projects will work just fine without Git being present. Here, too, PATH + `git` is used
so if there is a need on a user's system to use Git-based dependencies, the user can just
add the package to the profile and things will just work.

I feel that leaving this alone is cleaner than trying to fix the dependency (if we want to
keep it, it needs to be in propagated-inputs in order to keep Git around; I stumbled upon
this building a project with Git dependencies after doing a `guix gc`. However, given that
using Git dependencies is the exception and I think that minimizing dependencies is nicer
I opted to just remove the substition completely).

---
gnu/packages/elixir.scm | 5 -----
1 file changed, 5 deletions(-)

Toggle diff (16 lines)
diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
index 55e17f2901..f509c59ee3 100644
--- a/gnu/packages/elixir.scm
+++ b/gnu/packages/elixir.scm
@@ -60,11 +60,6 @@ (define-public elixir
(for-each make-file-writable (find-files "."))))
(add-after 'make-git-checkout-writable 'replace-paths
(lambda* (#:key inputs #:allow-other-keys)
- (substitute* '("lib/elixir/lib/system.ex"
- "lib/mix/lib/mix/scm/git.ex")
- (("(cmd\\(['\"])git" _ prefix)
- (string-append prefix
- (search-input-file inputs "/bin/git"))))
(substitute* '("lib/mix/lib/mix/release.ex"
"lib/mix/lib/mix/tasks/release.init.ex")
(("#!/bin/sh")
--
2.34.0
M
M
Maxime Devos wrote on 8 Mar 2022 23:16
5e1d2abc1008c43dd70a85999420d529980c2bd1.camel@telenet.be
Cees de Groot schreef op di 08-03-2022 om 20:52 [+0000]:
Toggle quote (3 lines)
> I feel that leaving this alone is cleaner than trying to fix the dependency (if we want to
> keep it, it needs to be in propagated-inputs in order to keep Git around;

Instead of propagation, I recommend substitution, like done currently.
Propagation is not necessary to ‘keep git around’ (assuming that the
store reference is not obfuscated by gzipping or the like).

If it's used at build-time instead of run-time, then git should be
moved to native-inputs, for cross-compilation reasons.

Greetings,
Maxime
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYifVxxccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7tv0AQDJoIGfzPsjTnIGId3E+kcY04qZ
mk3MxZ8RCkkj0jcN/QD/c9Z/61ESb6clBTp9GPzKT92dtM4LEXEr1gTqRyCMeQc=
=P2yc
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 8 Mar 2022 23:17
d40072710db6d1352dba3664f881c47411100788.camel@telenet.be
Cees de Groot schreef op di 08-03-2022 om 20:52 [+0000]:
Toggle quote (2 lines)
> * At build-time, Git is used to see if the build is inside a Git repo and if so, git info

That cannot ever have worked in the first place, since Guix does not
save the '.git' directory when downloading elixir's source code.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYifWChccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7vipAP9JudT4J/sNY++GM6xV6EIWpWBg
dYT50SRZcvbnMzLFHwEA5quWzqcl7fre9Zlcbsy0ANi7foz+PIiIGFreZ1DDSg4=
=1MrM
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 8 Mar 2022 23:18
c5a44f63897dafaafff33d4cdcd5c17324bf9029.camel@telenet.be
Cees de Groot schreef op di 08-03-2022 om 20:52 [+0000]:
Toggle quote (2 lines)
>   uses PATH + `git` so the Git version from the inputs is used which is just fine.

Due to cross-compilation reasons, this is not fine, it should use the
git from native-inputs instead.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYifWOhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7nKWAQCylSTfi61xYr9qtawkwphhcC5b
eAK6/HwQgIr7Kp/uSgEAl3pcPOJRwgaCa96f1er7efpCfaZLDi7RldnkjQCQ8gM=
=HHY0
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 8 Mar 2022 23:22
5f60c94ec46bf7348c3f1906957dc3cbb4d9d395.camel@telenet.be
Cees de Groot schreef op di 08-03-2022 om 20:52 [+0000]:
Toggle quote (6 lines)
> * At run-time, Git is used by Mix if, and only if, there are any Git-based dependencies. This
>   is not the normal case, and in that sense Git is an optional dependency of Elixir - most
>   projects will work just fine without Git being present. Here, too, PATH + `git` is used
>   so if there is a need on a user's system to use Git-based dependencies, the user can just
>   add the package to the profile and things will just work.

If it's optional and not used most of the time, removing
it seems fine to me, though this seems useful information for the
description. Also, it would be nice if 'elixir' were patched
to emit a nice message when 'git' is not found. Suggestion:

This project required 'git', but it is not in $PATH. It can be
installed into the user profile with `guix install git`.

You might want to contact whoever added the substitution originally,
to see what the original reasons were.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYifXMhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7q7UAP45wDMIM6e9HIRusznaKGZa93bk
oP8mUmH8GJiZ7sJBgwEAxYKovszQztu8RTbsQWWOz28xlUMgo+nP7AbZr5caSQA=
=cc7j
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 9 Mar 2022 08:31
(name . Cees de Groot)(address . cg@evrl.com)(address . 54304@debbugs.gnu.org)
090dccee9fc3834656bbe416364a9a337122a2fb.camel@telenet.be
Cees de Groot schreef op wo 09-03-2022 om 02:39 [+0000]:
Toggle quote (7 lines)
> > [...]
> > That cannot ever have worked in the first place, since Guix
> > does not save the '.git' directory when downloading elixir's source
> > code.

> That’s correct and fine. The info is informational at most  

How can being completely broken be correct and fine?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYihXwBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7pr1AQDfGqFcumXY6bg7sxxJEQmZXnLm
cia/7AbpZo/4wsccOwD/WvE1oQjlzhDIfJk1ufGLBaRSACKFBWU5NFTTnI/zOQo=
=WeWl
-----END PGP SIGNATURE-----


C
C
Cees de Groot wrote on 9 Mar 2022 18:29
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 54304@debbugs.gnu.org)
ExhgBMh19WrDLQHI-IOvmUDtnsZhoC7V_oAtrNS89idRnqtYgXQRaBTthBngQCRkFa-P0pSXOPwDAyIXL56CLBjGF-vHP4KEQUEbLkhz-4s=@evrl.com
From the docs:

":revision - short Git revision hash. If Git was not available at building time, it is set to """ (https://hexdocs.pm/elixir/System.html#build_info/0)

So if git is not available - either because the executable is not there or because the build checkout is not from Git, the revision hash is set to the empty string, which is in accordance with the docs and what the Guix build has been doing all along (because, as you said, at build time, .git isn't there).

So for build time, cross-compiling or not, we don't need Git.

------- Original Message -------

On Wednesday, March 9th, 2022 at 02:31, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (17 lines)
> Cees de Groot schreef op wo 09-03-2022 om 02:39 [+0000]:
>
> > > [...]
> > >
> > > That cannot ever have worked in the first place, since Guix
> > >
> > > does not save the '.git' directory when downloading elixir's source
> > >
> > > code.
>
> > That’s correct and fine. The info is informational at most
>
> How can being completely broken be correct and fine?
>
> Greetings,
>
> Maxime.
C
C
Cees de Groot wrote on 9 Mar 2022 18:31
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 54304@debbugs.gnu.org)
cU5FfmYRpITfhryoKWDl9Fk9O4bHdSY6qH-1r-XoPShMPsucSfjzsg-9qAge_ewWi5mt-hnBlntnc0F7CO1RmSnibVrYdhaEHIMXnoff6xc=@evrl.com
I think changing the behaviour of a programming language just to be helpful to developers is something that one may consider for upstream, but certainly not in the context of a packaging system like Guix - that just will breed confusion.

As it is, the error message thrown by Elixir when Git is not there is very easy to interpret for developers (and _only_ at development time can this happen!), no need to go overboard here. Unless, of course, you think it is useful to submit an upstream patch, feel free to do so.

------- Original Message -------

On Tuesday, March 8th, 2022 at 17:22, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (31 lines)
> Cees de Groot schreef op di 08-03-2022 om 20:52 [+0000]:
>
> > * At run-time, Git is used by Mix if, and only if, there are any Git-based dependencies. This
> >
> >   is not the normal case, and in that sense Git is an optional dependency of Elixir - most
> >
> >   projects will work just fine without Git being present. Here, too, PATH + `git` is used
> >
> >   so if there is a need on a user's system to use Git-based dependencies, the user can just
> >
> >   add the package to the profile and things will just work.
>
> If it's optional and not used most of the time, removing
>
> it seems fine to me, though this seems useful information for the
>
> description. Also, it would be nice if 'elixir' were patched
>
> to emit a nice message when 'git' is not found. Suggestion:
>
> This project required 'git', but it is not in $PATH. It can be
>
> installed into the user profile with `guix install git`.
>
> You might want to contact whoever added the substitution originally,
>
> to see what the original reasons were.
>
> Greetings,
>
> Maxime.
C
C
Cees de Groot wrote on 9 Mar 2022 18:35
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 54304@debbugs.gnu.org)
vzMnya4Wgd5OVun0QL9Rb6Yz8i-gpXWRsqldCku8vMVCEbU5_G_KnikguFe-d-ZN067kP1qtJo9liNrWraPfLzowJZy5zYJvdGyNJaumbyo=@evrl.com
Toggle quote (2 lines)
> Propagation is not necessary to ‘keep git around’ (assuming that the

Well.... the whole reason that I stumbled upon this was that the compile-time substitution referred to a Git version that got GC'd. And I think that that is the different between regular inputs and propagated inputs, whether inputs become eligible for GC at run-time or not. If I'm misunderstanding something there, something else caused that version of Git to get GC'd and I'd be more than happy to be corrected in my assumptions.
T
T
Tobias Geerinckx-Rice wrote on 9 Mar 2022 18:59
Re: [bug#54304] [PATCH] Don't fix git executable location during Elixir build
(address . 54304@debbugs.gnu.org)
3FC21903-C19B-49C1-B865-7D15E1B3EC74@tobias.gr
On 9 March 2022 17:35:25 UTC, Cees de Groot <cg@evrl.com> wrote:
Toggle quote (4 lines)
>> Propagation is not necessary to ‘keep git around’ (assuming that the
>
>Well.... the whole reason that I stumbled upon this was that the compile-time substitution referred to a Git version that got GC'd.

This simply Should Not happen. Guix's GC model (inherited from Nix) is brutally simple: if the raw string /gnu/store/xxx occurs anywhere within a protected /gnu/store/yyy (e.g. in a binary), then xxx is also protected, recursively.

Assuming those assumptions hold here it's a 'mystery' why git got GC'd. From experience and for our collective peace of mind I'd say it's more likely that they didn't hold somehow, than that there's a serious GC bug :-)

Toggle quote (2 lines)
> And I think that that is the different between regular inputs and propagated inputs, whether inputs become eligible for GC at run-time or not.

So, no. Completely unrelated. The GC has no concept of time at all. This isn't Gentoo.

Propagated inputs are 'oh, here's this extra thing I was unable to properly patch, please add it to the profile and treat it as a GC reference anyway'.

This is ugly and regular, non-propagated inputs are always preferred. Some software just makes them too painful.
Cees,

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.
M
M
Maxime Devos wrote on 9 Mar 2022 20:45
Re: [bug#54304] [PATCH] Don't fix git executable location during Elixir build
(name . Cees de Groot)(address . cg@evrl.com)(address . 54304@debbugs.gnu.org)
919b8ca66b9548aa0e3cf682b9e293f7ed28b2a8.camel@telenet.be
Cees de Groot schreef op wo 09-03-2022 om 17:31 [+0000]:
Toggle quote (2 lines)
> I think changing the behaviour of a programming language just to be helpful to developers

Developers are users too and users can be developers. Furthermore,
Elixir is an implementation of a programming language, so aren't all
users of Elixir automatically developers?

I'm not sure how exactly Elixir integrates with git but I assume the
integration can be very useful.

Also, this does not change the behaviour of the language, it only
adjusts a detail of the implementation: the error message for
indicating that git is missing is adjusted.

Toggle quote (3 lines)
> is something that one may consider for upstream, but certainly not in the context
> of a packaging system like Guix - that just will breed confusion.

How could better error messages breed confusion?

Also, this seems a change that would absolutely _not_ be considered
upstream. Why would upstream have distro-specific error messages? If
the new error message is Guix-specific, wouldn't Guix be the logical
place to have it?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYikD5RccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7gppAP45vq8lFQRRs+nLssm3L7rBLQzZ
q0ZPo5RcbDwVwdFssAD/coZUNom2+Cus2qHJ3O/PxMf0t3Z2hiLr4CskcVHNpQ0=
=PAGC
-----END PGP SIGNATURE-----


C
C
Cees de Groot wrote on 9 Mar 2022 22:01
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
BLnyODUm-yZNU1xZMtYiaY3geuDk0O7KQALAgfrx-7bnEsKDlS9rQUJWNmPebVfjPdgRwlrW1Mqwa60k8ZJLyOMHuqbK7TYFsBeYbkf8h1I=@evrl.com
On Wednesday, March 9th, 2022 at 12:59, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

Toggle quote (2 lines)
> This simply Should Not happen. Guix's GC model (inherited from Nix) is brutally simple: if the raw string /gnu/store/xxx occurs anywhere within a protected /gnu/store/yyy (e.g. in a binary), then xxx is also protected, recursively.

So how does Guix figure out what to keep and what not? I mean, in this case the patched string will land in a compiled .BEAM file which very well may have the string obfuscated (I need to check how the VM stores strings in binaries).
T
T
Tobias Geerinckx-Rice wrote on 9 Mar 2022 22:49
Re: [bug#54304] [PATCH] Don't fix git executable location during Elixir build
(name . Cees de Groot)(address . cg@evrl.com)
2D451842-1953-44AE-A6E8-B50EC77A26A0@tobias.gr
Cees,

Yeah, this happens sometimes and will hide these references from what is a simple and therefore very fast string search.

It's why we install uncompressed .jar files and disable an obscure (and arguably unnoticable) GCC optimisation that hacks strings into incontiguous chunks. If BEAM somehow obfuscates store references we'll have to find a similar work-around to stop it. Let us know what you find.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.
C
C
Cees de Groot wrote on 11 Mar 2022 22:33
Re: [bug#54304] [PATCH] Don't fix git executable location during Elixir build
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
_Zczh2RFJMdo3Xxkpzzzfq2LT3_PlZVB2huEPbAOcMoPnxeZWSZD7_BJfMZewYiM_LRQk4y6ScvTx_M7L-JQau-5IDMIe9G-req83waeb5o=@evrl.com
On Wednesday, March 9th, 2022 at 16:49, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
Toggle quote (2 lines)
> If BEAM somehow obfuscates store references we'll have to find a similar work-around to stop it. Let us know what you find.
>
Yup. BEAM files have literals stored in a single Deflated blob (https://beam-wisdoms.clau.se/en/latest/indepth-beam-file.html).So the scanning won't work.

Which means that either my patches should be merged or Git should be propagated. I'm not a super big fan of propagating optional dependencies, which is why I submitted the patch like this.
L
L
Ludovic Courtès wrote on 11 Mar 2022 22:51
Re: bug#54304: [PATCH] Don't fix git executable location during Elixir build
(name . Cees de Groot)(address . cg@evrl.com)
87wnh0w41s.fsf_-_@gnu.org
Hi,

Cees de Groot <cg@evrl.com> skribis:

Toggle quote (5 lines)
> On Wednesday, March 9th, 2022 at 16:49, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
>> If BEAM somehow obfuscates store references we'll have to find a similar work-around to stop it. Let us know what you find.
>>
> Yup. BEAM files have literals stored in a single Deflated blob (https://beam-wisdoms.clau.se/en/latest/indepth-beam-file.html). So the scanning won't work.

If we know what set of store references go in those blogs, we could
create a text file or something in #$output whose sole purpose is to
keep a reference to those store items.

For example, if we know those BEAM files contain a reference to Git, we
can add a phase like:

(lambda* (#:key inputs outputs #:allow-other-keys)
(symlink (search-input-file inputs "git")
(string-append (assoc-ref output "out")
"/libexec/elixir/.git")))

That way the GC will keep Git around.

Thoughts?

Ludo’.
M
M
Maxime Devos wrote on 11 Mar 2022 22:57
3772387f64195fabd6d4a69a4d29912e43896ba9.camel@telenet.be
Ludovic Courtès schreef op vr 11-03-2022 om 22:51 [+0100]:
Toggle quote (10 lines)
> If we know what set of store references go in those blogs, we could
> create a text file or something in #$output whose sole purpose is to
> keep a reference to those store items.
>
> For example, if we know those BEAM files contain a reference to Git, we
> can add a phase like:
>
>   (lambda* (#:key inputs outputs #:allow-other-keys)
>     (symlink (search-input-file inputs "git")

Doesn't that need to be "bin/git" instead of "git"?

Toggle quote (7 lines)
>              (string-append (assoc-ref output "out")
>                             "/libexec/elixir/.git")))
>
> That way the GC will keep Git around.
>
> Thoughts?

That is not sufficient if git acquires a graft.

Can elixir be patched to not compress the literals table (*)?
Alternatively, does deflate have some kind of "compression
level=0" setting -- perhaps we could do the same trick as
done for JARs?

(*) Preferably submitted upstream in some form, maybe with a
configuration flag?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYivFrhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7kQFAQDv0QE3g+zx0/zoD5Tq3+UTeZ0U
A0svmRKtHiJ2XDjuJgEApzTC/9Y3SGpZvFMxYXvgsjZwjCNroM6i11ggtK25dQw=
=vPIB
-----END PGP SIGNATURE-----


C
C
Cees de Groot wrote on 11 Mar 2022 23:01
l2mYwYLigQhrpSBhhoi-rlS7HNZWdsdIpu80iueL_TaW6O_hbIwKKYdL6R2h3jDnDSBrqXvgk_k8Ufn8zwtC8CmbFXy9oz-slDxoC9MugGw=@evrl.com
Can’t we just run the patch? Then everything works just fine. I’m a full time Elixir developer and I can guarantee you that nothing will break :)

Sent from ProtonMail for iOS

On Fri, Mar 11, 2022 at 16:57, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (32 lines)
> Ludovic Courtès schreef op vr 11-03-2022 om 22:51 [+0100]:
>> If we know what set of store references go in those blogs, we could
>> create a text file or something in #$output whose sole purpose is to
>> keep a reference to those store items.
>>
>> For example, if we know those BEAM files contain a reference to Git, we
>> can add a phase like:
>>
>> (lambda* (#:key inputs outputs #:allow-other-keys)
>> (symlink (search-input-file inputs "git")
>
> Doesn't that need to be "bin/git" instead of "git"?
>
>> (string-append (assoc-ref output "out")
>> "/libexec/elixir/.git")))
>>
>> That way the GC will keep Git around.
>>
>> Thoughts?
>
> That is not sufficient if git acquires a graft.
>
> Can elixir be patched to not compress the literals table (*)?
> Alternatively, does deflate have some kind of "compression
> level=0" setting -- perhaps we could do the same trick as
> done for JARs?
>
> (*) Preferably submitted upstream in some form, maybe with a
> configuration flag?
>
> Greetings,
> Maxime.
Attachment: file
M
M
Maxime Devos wrote on 11 Mar 2022 23:11
f7aef3e8429fd11e6e85da022780066385da06c1.camel@telenet.be
Cees de Groot schreef op vr 11-03-2022 om 22:01 [+0000]:
Toggle quote (4 lines)
> Can’t we just run the patch? Then everything works just fine. I’m a
> full time Elixir developer and I can guarantee you that nothing will
> break :)

FWIW, I'm not convinced of the value of removing 'git', as I don't
expect a significant decrease in closure size and it makes Elixir a
little less usable (only a tiny bit because git can be installed
manually, but still a bit).

The only remaining reasons for removing it, appear to be avoiding
having to tackle the reference obfuscating issue -- sooner or later
(*), I expect there will eventually be an elixir-build-system and a few
elixir packages. These elixir packages might need a few 'substitute*'-
style hardcoding. So eventually, I expect the issue will reappear
again and frequently at that, so we might as well try to fix it now.

(*) Especially since there's an Elixir developer in Guix!

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYivJDBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7uuqAP0T6doKwP5/zl/ETzuDZgSUok/Q
Hczbx6sO5EiNetOuGQD+L9YSoyr0/ltHQpZYddoG+2H2+KNqZCZAbeiql9/sWgE=
=yyJs
-----END PGP SIGNATURE-----


C
C
Cees de Groot wrote on 11 Mar 2022 23:36
WWBeielX0K08g-EXLiUTGaS1WVaXB-OBPqDO0Tks2kbPhz8lOpEdCV9qX_WBMnIIskckbTG2RDvVmlycgX_fWKoD316Xg2QcgqRbjGuWEYU=@evrl.com
Well, feel free to do the patching work. Realize that you are going to do work for a) a very small group of developers (Elixir is a small language and Guix isn’t hardly a widely spread system to begin with), b) a subset of those that need git dependencies, and c) a subset of _those_ that need these dependencies on a project source tree that itself was not checked out with git (otherwise the git executable will already be in the environment and everything will work).

Please let me know when you found that unicorn developer :)

Sent from ProtonMail for iOS

On Fri, Mar 11, 2022 at 17:11, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (21 lines)
> Cees de Groot schreef op vr 11-03-2022 om 22:01 [+0000]:
>> Can’t we just run the patch? Then everything works just fine. I’m a
>> full time Elixir developer and I can guarantee you that nothing will
>> break :)
>
> FWIW, I'm not convinced of the value of removing 'git', as I don't
> expect a significant decrease in closure size and it makes Elixir a
> little less usable (only a tiny bit because git can be installed
> manually, but still a bit).
>
> The only remaining reasons for removing it, appear to be avoiding
> having to tackle the reference obfuscating issue -- sooner or later
> (*), I expect there will eventually be an elixir-build-system and a few
> elixir packages. These elixir packages might need a few 'substitute*'-
> style hardcoding. So eventually, I expect the issue will reappear
> again and frequently at that, so we might as well try to fix it now.
>
> (*) Especially since there's an Elixir developer in Guix!
>
> Greetings,
> Maxime.
Attachment: file
M
M
Maxime Devos wrote on 11 Mar 2022 23:45
3df7ef98867c4077efc34a335b193a6fda333cb2.camel@telenet.be
Cees de Groot schreef op vr 11-03-2022 om 22:36 [+0000]:
Toggle quote (8 lines)
> Well, feel free to do the patching work. Realize that you are going
> to do work for a) a very small group of developers (Elixir is a small
> language and Guix isn’t hardly a widely spread system to begin with),
> b) a subset of those that need git dependencies, and c) a subset of
> _those_ that need these dependencies on a project source tree that
> itself was not checked out with git (otherwise the git executable
> will already be in the environment and everything will work). 

This is not only for the subset that uses git dependencies. It is for
anyone writing and using Elixir packages, see my paragraph about
reference baking (in general, not git-specific):

Toggle quote (8 lines)
> The only remaining reasons for removing it, appear to be avoiding
> having to tackle the reference obfuscating issue -- sooner or later
> (*), I expect there will eventually be an elixir-build-system and a
> few elixir packages. These elixir packages might need a few
> 'substitute*'- style hardcoding. So eventually, I expect the issue
> will reappear again and frequently at that, so we might as well try
> to fix it now.

More specifically, you could look at how, say, 'info-reader' uses
'substitute*', 'search-input-file', 'gunzip' and 'gzip'

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYivRIRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7opGAQCCAAUNyCWGHd4XPvnKKtlP3h0W
2iC1voPQRxJ1bpWHjwD+OlMO0b8648Y2DvzND/g2+M2qIReLNRQvfj9XDrcpywc=
=HJ63
-----END PGP SIGNATURE-----


C
C
Cees de Groot wrote on 11 Mar 2022 23:55
GsLipzuyvGFw-1eDvwcbeo7Vg9i3dgnXvPJIB8-K0W28XAH5-xA-6balBJoSdhDAinmizkQaJsBAkdQbNBAUd4fKzDgvN4loxhlUBtNIVlM=@evrl.com
If Guix ever gets elixir packages, that can be tackled.

I’m bowing out of this discussion. If my patch gets accepted then all good, if not, I’ll move it to my private channel and keep being happy there.

Sent from ProtonMail for iOS

On Fri, Mar 11, 2022 at 17:45, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (26 lines)
> Cees de Groot schreef op vr 11-03-2022 om 22:36 [+0000]:
>> Well, feel free to do the patching work. Realize that you are going
>> to do work for a) a very small group of developers (Elixir is a small
>> language and Guix isn’t hardly a widely spread system to begin with),
>> b) a subset of those that need git dependencies, and c) a subset of
>> _those_ that need these dependencies on a project source tree that
>> itself was not checked out with git (otherwise the git executable
>> will already be in the environment and everything will work).
>
> This is not only for the subset that uses git dependencies. It is for
> anyone writing and using Elixir packages, see my paragraph about
> reference baking (in general, not git-specific):
>
>> The only remaining reasons for removing it, appear to be avoiding
>> having to tackle the reference obfuscating issue -- sooner or later
>> (*), I expect there will eventually be an elixir-build-system and a
>> few elixir packages. These elixir packages might need a few
>> 'substitute*'- style hardcoding. So eventually, I expect the issue
>> will reappear again and frequently at that, so we might as well try
>> to fix it now.
>
> More specifically, you could look at how, say, 'info-reader' uses
> 'substitute*', 'search-input-file', 'gunzip' and 'gzip'
>
> Greetings,
> Maxime.
Attachment: file
M
M
Maxime Devos wrote on 12 Mar 2022 00:16
13042012c34522fc9ed26746d11cc88b22f1ec6a.camel@telenet.be
Cees de Groot schreef op vr 11-03-2022 om 22:36 [+0000]:
Toggle quote (2 lines)
> Well, feel free to do the patching work.

I'm just here reviewing things, looking for possible better
alternatives, etc.

Toggle quote (10 lines)
> Realize that you are going to do work for a) a very small group of
> developers (Elixir is a small language and Guix isn’t hardly a widely
> spread system to begin with), b) a subset of those that need git
> dependencies, and c) a subset of _those_ that need these dependencies
> on a project source tree that itself was not checked out with git
> (otherwise the git executable will already be in the environment and
> everything will work). 
>
> Please let me know when you found that unicorn developer :)

a) You're an Elixir developer, using Guix, and doing packaging work for
Elixir in Guix. Also, how is the popularity of Guix relevant on
guix-patches@, and how is the popularity of Elixir relevant when
this whole patch is about improving the Elixir package?
b) does not seem relevant to me, see other e-mails (about removing a
feature not worth the decrease in closure size IMO, and about
non-git references)
c) It's a bit niche; it would be a very nice thing of Guix to support
that niche.

Also, being checked out with git does not imply that git is
in the environment, it's possible to first set up a git repository
and later enter a pure environment for development (guix shell --
pure elixir elixir-foo elixir-bar). I often do this (not with
elixir, but with some other packages).

TBC, what do you mean with ‘unicorn developer’ here?

a) someone implementing this
b) someone in the subset

If (a), I was kind of hinting that you seem to be in a perfect position
to do so (you're an Elixir developer (*) in Guix and you seem to have
some knowledge of the serialisation formats).

(*) I'm assuming "Elixir developer" = "a developer of the Elixir
implementation" here.

Toggle quote (6 lines)
> If Guix ever gets elixir packages, that can be tackled.
>
> I’m bowing out of this discussion. If my patch gets accepted then all
> good, if not, I’ll move it to my private channel and keep being happy
> there.

Ok, but I'm a bit confused on why you don't seem interested in fixing
the reference issue and why you write ‘ever’ instead of ‘when’ because
you're both an Elixir and Guix developer. (You don't have to answer,
not answering is fine.)

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYivYQhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7l3pAQDQwm2ZyoKQ5RwJUKB38BiFqHpQ
lV7TpJEJISOeZnbNhwD+Nvvh7Lt2vxvygcOF4aB+BnkaYEDSqNpRr8N7WiDgMAE=
=riV4
-----END PGP SIGNATURE-----


C
C
Cees de Groot wrote on 12 Mar 2022 00:23
(name . Maxime Devos)(address . maximedevos@telenet.be)
iwOMYzqUfdK9q22AjfMMYXpy5UWb9SiAQaAJx6pJ3ldEGteYcsPqWzNHvb5MhFMN9Uv91or1PF-xFRFDGopRjfRuAtJw2xtlZ3vJUgNo64s=@evrl.com
On Friday, March 11th, 2022 at 18:16, Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (2 lines)
> Ok, but I'm a bit confused on why you don't seem interested in fixing the reference issue [...]

I am interested in fixing the bug in the current package. And, I'm quite honest there, I'm in itch-scratching mode so I'm not interested in fixing potential, future, maybe issues :). My patch works, and yes, I'm more than happy to improve and iterate on it _if_ - and to me, that's a very big if - more issues appear.
L
L
Ludovic Courtès wrote on 13 Mar 2022 23:14
(name . Maxime Devos)(address . maximedevos@telenet.be)
8735jlts90.fsf_-_@gnu.org
Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (22 lines)
> Ludovic Courtès schreef op vr 11-03-2022 om 22:51 [+0100]:
>> If we know what set of store references go in those blogs, we could
>> create a text file or something in #$output whose sole purpose is to
>> keep a reference to those store items.
>>
>> For example, if we know those BEAM files contain a reference to Git, we
>> can add a phase like:
>>
>>   (lambda* (#:key inputs outputs #:allow-other-keys)
>>     (symlink (search-input-file inputs "git")
>
> Doesn't that need to be "bin/git" instead of "git"?
>
>>              (string-append (assoc-ref output "out")
>>                             "/libexec/elixir/.git")))
>>
>> That way the GC will keep Git around.
>>
>> Thoughts?
>
> That is not sufficient if git acquires a graft.

Argh, good point.

Now, I agree with Cees that we need to be pragmatic here and opt for a
“good enough” solution.

So I went ahead and applied the initial patch that Cees posted.

However, that ‘replace-paths’ phase also touches references to /bin/sh;
are they also a problem after GC?

Thanks,
Ludo’.
C
C
Cees de Groot wrote on 13 Mar 2022 23:16
05sp-vgNcatmxmXI-wpwB7VDLc4eeac9O3ez4sXrHlWPaiA0OvqlJdeZVfgfOw917PTJ7DQ8-8VZbNJQAZbD_F-RO8w-fEaR52f-Enhh1_8=@evrl.com
These references only touch shell scripts so I think they should be just fine. I’ll give it a look when I’m back at work after the weekend to be sure though.

Sent from ProtonMail for iOS

On Sun, Mar 13, 2022 at 18:14, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)
> However, that ‘replace-paths’ phase also touches references to /bin/sh;
> are they also a problem after GC?
>
> Thanks,
> Ludo’.
Attachment: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 54304@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 54304
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch