guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#48463] gnu: Add j.


From: Liliana Marie Prikler
Subject: [bug#48463] gnu: Add j.
Date: Sun, 16 Jan 2022 20:53:29 +0100
User-agent: Evolution 3.42.1

Hi,

Am Montag, dem 17.01.2022 um 00:19 +0900 schrieb
elaexuotee@wilsonb.com:
> > > Interesting idea. How about just always forcing a MINOR part,
> > > setting to "0" if upstream doesn't have one?
> > That'd declare regular releases as MAJOR.0 in the version field,
> > which I'm not sure if we want that.  In the case of random commits
> > I'm less reserved, as they don't correspond to releases anyway.
> 
> I see your point. In fact, upstream releases start with MINOR part "a"
> and "count up" through the letters over the course of a year. It's a
> pretty simple scheme. For example, J 901 started at "j901-release-a"
> and ended at "j901-release-f".
> 
> When I originally wrote this package, I noticed that the release tag
> for the first J 902 was "j902-release", and so treaded MINOR as
> potentially optional.
> However, after checking upstream's forums, this looks to just be a git
> tag mishap.
> 
> How about we just go ahead and treat MINOR as mandatory as well?
In other words minor should always have a value >= "a" and 902 was just
missing it?  Fair enough, in that case making version mandatory sounds
like the way to go.

> > > If you have a better idea, I am all ears.
> > You could define that file-union right after ijconsole.  If you want
> > to
> > golf even more, you could define ijconsole inside that file-union,
> > i.e.
> >   (define jsoftware-aux-files
> >     (file-union "jsoftware-aux-files"
> >       `(("profile.ijs" ,(search-aux-file ...)
> >         ("ijconsole" ,(program-file ...))))
> > 
> > I'm not quite sure if you want to use jsoftware-aux-files directly as
> > input or whether it's wiser to stuff it into another union like 
> > (file-union "jsoftware-aux-input" `(("aux" ,jsoftware-aux-files))).
> > search-input-file will probably do the right thing regardless.
> > The new style should also still work with assoc-ref, it'd just be
> > weirder to look at.  Lastly, you could code up a (search-file-input)
> > just in case; I'm not sure if we have one already.
> 
> The file-union seems like a cludgy workaround to me. What we really
> want is an easy, direct way to get handles on the input files. Heck,
> program-file objects already have a name property; why can't we use
> that? Attached patches are a proof-of-concept.
That proof of concept does look nice, but for one we're trying to move
away from labels, and for the other, it's on a scale that I don't want
to decide as part of a package addition.  If you feel it has value
outside of the proposed usage for j, discussing it under a different
number or perhaps on guix-devel might be worth it.

> That said, if this is going to turn into a big rabbit hole, can we just
> munge the J package inputs into whatever you think is best?
As said in my previous mail, that'd be
> >   (define jsoftware-aux-files
> >     (file-union "jsoftware-aux-files"
> >       `(("profile.ijs" ,(search-aux-file ...)
> >         ("ijconsole" ,(program-file ...))))
In my personal opinion, you can then simply add jsoftware-aux-files as
input and (search-input-file "ijconsole") instead of the current assoc-
ref.  WDYT?

Don't worry, I don't plan to drag this out too long, but I also don't
planning on pushing this today.  There are definitely some stylistic
choices that I want to make under the considerations here (basically,
we can just merge major and minor into a single base that'd be "903.a",
for example), but it's almost bedtime and I want to relax a little
before going to sleep.

Cheers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]