[bug#70632,1/2] aux-files: comp-integrity: Adjust for newer emacs.

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi,
>
> the change itself LGTM, but I think it should be accompanied by a
> change to Emacs 30 and also we should really try to version it because
> it rebuilds Emacs as a whole.  The emacs-team branch hasn't been used
> for a while and I think there's nothing big there; and neither is there
> a need to exercise it if we just add another file and replace the
> phase.
>
> Cheers

I think some people might want to build newer Emacs's before the 30
release.  Like how people wanted the pgtk and tree-sitter features
early.  People might want to try the new GC that's being developed.

I'm not a fan of adding another file so I came up with this solution.
See attached patch.

If we believe that a core-updates merge will occur before Emacs 30 then
I would like to see my original patch applied there.

Thanks,

Morgan

Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Hi,
> > 
> > the change itself LGTM, but I think it should be accompanied by a
> > change to Emacs 30 and also we should really try to version it
> > because it rebuilds Emacs as a whole.  The emacs-team branch hasn't
> > been used for a while and I think there's nothing big there; and
> > neither is there a need to exercise it if we just add another file
> > and replace the phase.
> > 
> > Cheers
> 
> I think some people might want to build newer Emacs's before the 30
> release.  Like how people wanted the pgtk and tree-sitter features
> early.  People might want to try the new GC that's being developed.
That's fair and we aim to support that case.

> I'm not a fan of adding another file so I came up with this solution.
> See attached patch.
Hmm, I'm a bit torn on the solution.  On one hand, it is a local
solution with just a phase, on the other having the file makes it
easier to just mv it.

> If we believe that a core-updates merge will occur before Emacs 30
> then I would like to see my original patch applied there.
It'd be only emacs-team, not core-updates, but we could do this
"quickly" either way.  But the point behind those is to keep them small
and manageable in a sense, so core-updates is typically not concerned
with leaves or leaf-like stuff.

Cheers

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> I'm not a fan of adding another file so I came up with this solution.
>> See attached patch.
> Hmm, I'm a bit torn on the solution.  On one hand, it is a local
> solution with just a phase, on the other having the file makes it
> easier to just mv it.

I don't understand the trade-offs here.  I'm a fan of keeping data as
close to where it's used as possible (so ideally in emacs.scm).  I'm not
sure what advantages putting it in a file gives over this solution.

Just to be clear: what do you mean by adding another file?  I assume you
mean adding a comp-integrity-next.el file which is almost identical to
comp-integrity.el with these small changes in place.

>> If we believe that a core-updates merge will occur before Emacs 30
>> then I would like to see my original patch applied there.
> It'd be only emacs-team, not core-updates, but we could do this
> "quickly" either way.  But the point behind those is to keep them small
> and manageable in a sense, so core-updates is typically not concerned
> with leaves or leaf-like stuff.

I don't think I understand how our branch development stuff works.  I
thought we put large dependency changes on core-updates so that the CI
could chew through everything and make sure it's good before merging.

Regardless, I trust the team to do the proper procedures.  I simply
believe we might do more package fiddling before Emacs 30 and that
potential problems might be assuaged if the comp-integrity file was more
forgiving and supported every Emacs equally.  Thus, I would encourage it
to be applied in the appropriate place now to avoid potential headache
but if we wish to wait for Emacs 30 that would also be a valid choice.

Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
> > > Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > > 
> > > I'm not a fan of adding another file so I came up with this
> > > solution.  See attached patch.
> > Hmm, I'm a bit torn on the solution.  On one hand, it is a local
> > solution with just a phase, on the other having the file makes it
> > easier to just mv it.
> 
> I don't understand the trade-offs here.  I'm a fan of keeping data as
> close to where it's used as possible (so ideally in emacs.scm).  I'm
> not sure what advantages putting it in a file gives over this
> solution.
The advantage lies in only rebuilding Emacs 30.

> Just to be clear: what do you mean by adding another file?  I assume
> you mean adding a comp-integrity-next.el file which is almost
> identical to comp-integrity.el with these small changes in place.
Yes.

> > > If we believe that a core-updates merge will occur before Emacs
> > > 30 then I would like to see my original patch applied there.
> > It'd be only emacs-team, not core-updates, but we could do this
> > "quickly" either way.  But the point behind those is to keep them
> > small and manageable in a sense, so core-updates is typically not
> > concerned with leaves or leaf-like stuff.
> 
> I don't think I understand how our branch development stuff works.  I
> thought we put large dependency changes on core-updates so that the
> CI could chew through everything and make sure it's good before
> merging.
Most stuff is now organized within teams that have "smaller"
responsibilities.  I'm responsible for getting Emacs and Gnome updates
way later than we could…

> Regardless, I trust the team to do the proper procedures.  I simply
> believe we might do more package fiddling before Emacs 30 and that
> potential problems might be assuaged if the comp-integrity file was
> more forgiving and supported every Emacs equally.  Thus, I would
> encourage it to be applied in the appropriate place now to avoid
> potential headache but if we wish to wait for Emacs 30 that would
> also be a valid choice.
There are tradeoffs to be made here.  In principle, we could support
"every Emacs ever", in practice, it hardly makes sense.  If you need an
old Emacs in the future, you might as well use the built-in time
machine.

The right place is a new comp-integrity.el.  We can just mv it over the
old one once Emacs 30 is the default Emacs.  We don't yet know how the
help changes for 31, so we can't really ask a crystal ball to insert
the right check.

Cheers

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> > > Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> > > 
>> > > I'm not a fan of adding another file so I came up with this
>> > > solution.  See attached patch.
>> > Hmm, I'm a bit torn on the solution.  On one hand, it is a local
>> > solution with just a phase, on the other having the file makes it
>> > easier to just mv it.
>> 
>> I don't understand the trade-offs here.  I'm a fan of keeping data as
>> close to where it's used as possible (so ideally in emacs.scm).  I'm
>> not sure what advantages putting it in a file gives over this
>> solution.
> The advantage lies in only rebuilding Emacs 30.
>
I still feel like I'm conceptually missing something here.  Emacs 30
doesn't actually exist, right?  We are currently on Emacs 29.
emacs-next is the closest thing we have to Emacs 30.  Regardless of if
we create a new file or use my phase I sent, we will only be rebuilding
the emacs-next stuff.  The current emacs (29) is being left alone.

>> Regardless, I trust the team to do the proper procedures.  I simply
>> believe we might do more package fiddling before Emacs 30 and that
>> potential problems might be assuaged if the comp-integrity file was
>> more forgiving and supported every Emacs equally.  Thus, I would
>> encourage it to be applied in the appropriate place now to avoid
>> potential headache but if we wish to wait for Emacs 30 that would
>> also be a valid choice.
> There are tradeoffs to be made here.  In principle, we could support
> "every Emacs ever", in practice, it hardly makes sense.  If you need an
> old Emacs in the future, you might as well use the built-in time
> machine.
>
> The right place is a new comp-integrity.el.  We can just mv it over the
> old one once Emacs 30 is the default Emacs.  We don't yet know how the
> help changes for 31, so we can't really ask a crystal ball to insert
> the right check.

Ok I think I now sort of see your point.  You don't want a build up of
legacy support code in our files.  I do understand and support that and
will send a patch of that nature if you would like.  However, I do think
at least supporting all of the current Emacs packages in guix is a nice
thing to do.

In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
condition to support emacs 28.  I don't think we ever use that path
anymore but it is nice to have a robust function that "just works".
Espiaclly back when we did have emacs 28 and 29 packages in guix.

It is my personal opinion, that we should have the file support Emacs 29
and 30 for simplicity sake.  But again, if you disagree with me (which
is valid), I'll send you a patch creating a new file.

Am Mittwoch, dem 01.05.2024 um 16:06 -0400 schrieb Morgan Smith:
> 
> I still feel like I'm conceptually missing something here.  Emacs 30
> doesn't actually exist, right?  We are currently on Emacs 29.
> emacs-next is the closest thing we have to Emacs 30.  Regardless of
> if we create a new file or use my phase I sent, we will only be
> rebuilding the emacs-next stuff.  The current emacs (29) is being
> left alone.
> 
> > 
> [...]
> Ok I think I now sort of see your point.  You don't want a build up
> of legacy support code in our files.  I do understand and support
> that and will send a patch of that nature if you would like. 
> However, I do think at least supporting all of the current Emacs
> packages in guix is a nice thing to do.
> 
> It is my personal opinion, that we should have the file support Emacs
> 29 and 30 for simplicity sake.  But again, if you disagree with me
> (which is valid), I'll send you a patch creating a new file.
TL;DR: If we do a new file or a phase, we only rebuild emacs-next.  If
we modify the file in-place, we rebuild emacs, because it uses it. 
Between a phase and a new file, a new file is preferable, because we
can then 'mv' it over the old one.

> In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
> condition to support emacs 28.  I don't think we ever use that path
> anymore but it is nice to have a robust function that "just works".
> Espiaclly back when we did have emacs 28 and 29 packages in guix.
This is somewhat legacy code that has grown that way back when Emacs 29
was emacs-next.  There was no good reason to drop it with the switch,
but come Emacs 30, 31, and maintainability might be one.

Cheers