Hi RDE!
Currently RDE services are trying to save shepherd log files in
XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they
are doing this in (@ (shepherd support) %user-log-dir)/[].log (which
translates to XDG_STATE_HOME/shepherd/[].log.
I think we would benefit from a little more standardization. IMO, I like
a tiny bit more the RDE approach, but not enough to consider doing this
proposition to guix upstream, neither to redefine guix-defined home
services, so I'm willing to make the change (ie. from
XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),
but would like to gather some feedback before anything.
This would be a good opportunity to also finish what I started on
msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the
standard ~/.local/state (last XDG base dir revision), and maybe anchor
that in a Decision Record for later contributions. WDYT ?
--
Best regards,
Nicolas Graves
> Hi RDE!> > Currently RDE services are trying to save shepherd log files in> XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they> are doing this in (@ (shepherd support) %user-log-dir)/[].log (which> translates to XDG_STATE_HOME/shepherd/[].log.> > I think we would benefit from a little more standardization. IMO, I like> a tiny bit more the RDE approach, but not enough to consider doing this> proposition to guix upstream, neither to redefine guix-defined home> services, so I'm willing to make the change (ie. from> XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),> but would like to gather some feedback before anything. > > This would be a good opportunity to also finish what I started on> msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the> standard ~/.local/state (last XDG base dir revision), and maybe anchor> that in a Decision Record for later contributions. WDYT ?
There's also the option not to change anything in guix, but to
ungexp/gexp the log-file in the service to keep the log in /log/ dir,
that probably is simpler than I first thought.
We should settle for one approach or the other. Still waiting for some
input here ;)
--
Best regards,
Nicolas Graves
On 2024-01-19 20:24, Nicolas Graves wrote:
>> Hi RDE!>> >> Currently RDE services are trying to save shepherd log files in>> XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they>> are doing this in (@ (shepherd support) %user-log-dir)/[].log (which>> translates to XDG_STATE_HOME/shepherd/[].log.>> >> I think we would benefit from a little more standardization. IMO, I like>> a tiny bit more the RDE approach, but not enough to consider doing this>> proposition to guix upstream, neither to redefine guix-defined home>> services, so I'm willing to make the change (ie. from>> XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),>> but would like to gather some feedback before anything. >> >> This would be a good opportunity to also finish what I started on>> msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the>> standard ~/.local/state (last XDG base dir revision), and maybe anchor>> that in a Decision Record for later contributions. WDYT ?
Hm, I didn't recieve the original message.
>> There's also the option not to change anything in guix, but to> ungexp/gexp the log-file in the service to keep the log in /log/ dir,> that probably is simpler than I first thought.>> We should settle for one approach or the other. Still waiting for some> input here ;)
Standardization of log files is a really good idea. Unfortunatelly,
guix services are not flexible enough and we can't provide the function
for generating log-file/dir depending on the use case: For example, I
want to build a dev environment out of home-services and start using
shepherd as docker-compose alternative and it will have a different log
dir.
Anyway, I think that /log dir is more apropriate IMO, because it doesn't
matter who manages the service shepherd or whoever.
Writing down the decision would be great, yes.
--
Best regards,
Andrew Tropin
On 2024-01-23 12:01, Andrew Tropin wrote:
> On 2024-01-19 20:24, Nicolas Graves wrote:>>>> Hi RDE!>>>>>> Currently RDE services are trying to save shepherd log files in>>> XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they>>> are doing this in (@ (shepherd support) %user-log-dir)/[].log (which>>> translates to XDG_STATE_HOME/shepherd/[].log.>>>>>> I think we would benefit from a little more standardization. IMO, I like>>> a tiny bit more the RDE approach, but not enough to consider doing this>>> proposition to guix upstream, neither to redefine guix-defined home>>> services, so I'm willing to make the change (ie. from>>> XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),>>> but would like to gather some feedback before anything.>>>>>> This would be a good opportunity to also finish what I started on>>> msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the>>> standard ~/.local/state (last XDG base dir revision), and maybe anchor>>> that in a Decision Record for later contributions. WDYT ?>> Hm, I didn't recieve the original message.>>>>> There's also the option not to change anything in guix, but to>> ungexp/gexp the log-file in the service to keep the log in /log/ dir,>> that probably is simpler than I first thought.>>>> We should settle for one approach or the other. Still waiting for some>> input here ;)>> Standardization of log files is a really good idea. Unfortunatelly,> guix services are not flexible enough and we can't provide the function> for generating log-file/dir depending on the use case: For example, I> want to build a dev environment out of home-services and start using> shepherd as docker-compose alternative and it will have a different log> dir.
Is it that unflexible? since it's a file-like that is used, it allows
some flexibility that guix uses, for instance :
(log-file mcron-configuration-log-file ;string | gexp
(thunked)
(default
(if (mcron-configuration-home-service?
this-mcron-configuration)
#~(string-append %user-log-dir "/mcron.log")
"/var/log/mcron.log")))
Can't we inherit from the shepherd service defined in guix, then adapt
from there the value of log-file for this kind of flexibility ?
>> Anyway, I think that /log dir is more apropriate IMO, because it doesn't> matter who manages the service shepherd or whoever.
Yes, I agree with this and I think we can enforce that without too much
work in the case we can inherit from a shepherd service.
>> Writing down the decision would be great, yes.
Next task then I guess ;)
--
Best regards,
Nicolas Graves
On 2024-01-23 10:12, Nicolas Graves wrote:
> On 2024-01-23 12:01, Andrew Tropin wrote:>>> On 2024-01-19 20:24, Nicolas Graves wrote:>>>>>> Hi RDE!>>>>>>>> Currently RDE services are trying to save shepherd log files in>>>> XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they>>>> are doing this in (@ (shepherd support) %user-log-dir)/[].log (which>>>> translates to XDG_STATE_HOME/shepherd/[].log.>>>>>>>> I think we would benefit from a little more standardization. IMO, I like>>>> a tiny bit more the RDE approach, but not enough to consider doing this>>>> proposition to guix upstream, neither to redefine guix-defined home>>>> services, so I'm willing to make the change (ie. from>>>> XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),>>>> but would like to gather some feedback before anything.>>>>>>>> This would be a good opportunity to also finish what I started on>>>> msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the>>>> standard ~/.local/state (last XDG base dir revision), and maybe anchor>>>> that in a Decision Record for later contributions. WDYT ?>>>> Hm, I didn't recieve the original message.>>>>>>>> There's also the option not to change anything in guix, but to>>> ungexp/gexp the log-file in the service to keep the log in /log/ dir,>>> that probably is simpler than I first thought.>>>>>> We should settle for one approach or the other. Still waiting for some>>> input here ;)>>>> Standardization of log files is a really good idea. Unfortunatelly,>> guix services are not flexible enough and we can't provide the function>> for generating log-file/dir depending on the use case: For example, I>> want to build a dev environment out of home-services and start using>> shepherd as docker-compose alternative and it will have a different log>> dir.>> Is it that unflexible?
Yep, it is.
> since it's a file-like that is used, it allows some flexibility that> guix uses, for instance :>> (log-file mcron-configuration-log-file ;string | gexp> (thunked)> (default> (if (mcron-configuration-home-service?> this-mcron-configuration)> #~(string-append %user-log-dir "/mcron.log")> "/var/log/mcron.log")))
You can't do something like this:
(define dev-env
;; some pseudo-function somehow providing log-dir value to the
;; environment available for guix services
(with-specific-log-dir "state/logs"
(fold-services
(list (service mcron-service-type))
#:target-type home-profile-service-type)))
That's one of the reasons why we need to use features mechanism and rde
values in rde.
> Can't we inherit from the shepherd service defined in guix, then adapt> from there the value of log-file for this kind of flexibility ?
Can you show the example with pseudo-code?
>>>> Anyway, I think that /log dir is more apropriate IMO, because it doesn't>> matter who manages the service shepherd or whoever.>> Yes, I agree with this and I think we can enforce that without too much> work in the case we can inherit from a shepherd service.>>>> Writing down the decision would be great, yes.>> Next task then I guess ;)
(:
--
Best regards,
Andrew Tropin
On 2024-01-24 13:11, Andrew Tropin wrote:
> On 2024-01-23 10:12, Nicolas Graves wrote:>>> On 2024-01-23 12:01, Andrew Tropin wrote:>>>>> On 2024-01-19 20:24, Nicolas Graves wrote:>>>>>>>> Hi RDE!>>>>>>>>>> Currently RDE services are trying to save shepherd log files in>>>>> XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they>>>>> are doing this in (@ (shepherd support) %user-log-dir)/[].log (which>>>>> translates to XDG_STATE_HOME/shepherd/[].log.>>>>>>>>>> I think we would benefit from a little more standardization. IMO, I like>>>>> a tiny bit more the RDE approach, but not enough to consider doing this>>>>> proposition to guix upstream, neither to redefine guix-defined home>>>>> services, so I'm willing to make the change (ie. from>>>>> XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),>>>>> but would like to gather some feedback before anything.>>>>>>>>>> This would be a good opportunity to also finish what I started on>>>>> msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the>>>>> standard ~/.local/state (last XDG base dir revision), and maybe anchor>>>>> that in a Decision Record for later contributions. WDYT ?>>>>>> Hm, I didn't recieve the original message.>>>>>>>>>>> There's also the option not to change anything in guix, but to>>>> ungexp/gexp the log-file in the service to keep the log in /log/ dir,>>>> that probably is simpler than I first thought.>>>>>>>> We should settle for one approach or the other. Still waiting for some>>>> input here ;)>>>>>> Standardization of log files is a really good idea. Unfortunatelly,>>> guix services are not flexible enough and we can't provide the function>>> for generating log-file/dir depending on the use case: For example, I>>> want to build a dev environment out of home-services and start using>>> shepherd as docker-compose alternative and it will have a different log>>> dir.>>>> Is it that unflexible?>> Yep, it is.>>> since it's a file-like that is used, it allows some flexibility that>> guix uses, for instance :>>>> (log-file mcron-configuration-log-file ;string | gexp>> (thunked)>> (default>> (if (mcron-configuration-home-service?>> this-mcron-configuration)>> #~(string-append %user-log-dir "/mcron.log")>> "/var/log/mcron.log")))>> You can't do something like this:>> (define dev-env> ;; some pseudo-function somehow providing log-dir value to the> ;; environment available for guix services> (with-specific-log-dir "state/logs"> (fold-services> (list (service mcron-service-type))> #:target-type home-profile-service-type)))>> That's one of the reasons why we need to use features mechanism and rde> values in rde.>>> Can't we inherit from the shepherd service defined in guix, then adapt>> from there the value of log-file for this kind of flexibility ?>> Can you show the example with pseudo-code?>
Maybe we can start from something like this? If we can get the gexp out
of there in a procedure, we might have a procedure that could apply to
all configurations (with some more work of course) and just modify the
key #:log-file to put the logs in the right directory. This of course
only applies to records, but maybe it's enough for logs only? Or maybe
it's more simple to keep entering log-files by hand, I a noticed that
the two missing services I have that send logs in the wrong directory
are both from the mail-mcron outdated service.
(use-modules (guix gexp) (gnu services mcron))
(define (modify-record rcd field)
(let ((type (record-type-descriptor rcd)))
(when (and (record? rcd)
(member field (record-type-fields type)))
((record-modifier type field)
rcd
#~(let ((%user-log-dir (string-append (getenv "XDG_STATE_HOME") "/log")))
#$(((record-accessor type field) rcd) rcd)))))
rcd)
(modify-record
(mcron-configuration
(home-service? #t))
'log-file)
>>>>>> Anyway, I think that /log dir is more apropriate IMO, because it doesn't>>> matter who manages the service shepherd or whoever.>>>> Yes, I agree with this and I think we can enforce that without too much>> work in the case we can inherit from a shepherd service.>>>>>> Writing down the decision would be great, yes.>>>> Next task then I guess ;)>> (:
--
Best regards,
Nicolas Graves
On 2024-01-25 01:08, Nicolas Graves wrote:
> On 2024-01-24 13:11, Andrew Tropin wrote:>>> On 2024-01-23 10:12, Nicolas Graves wrote:>>>>> On 2024-01-23 12:01, Andrew Tropin wrote:>>>>>>> On 2024-01-19 20:24, Nicolas Graves wrote:>>>>>>>>>> Hi RDE!>>>>>>>>>>>> Currently RDE services are trying to save shepherd log files in>>>>>> XDG_STATE_HOME/log/[].log, while it seems that on the guix side, they>>>>>> are doing this in (@ (shepherd support) %user-log-dir)/[].log (which>>>>>> translates to XDG_STATE_HOME/shepherd/[].log.>>>>>>>>>>>> I think we would benefit from a little more standardization. IMO, I like>>>>>> a tiny bit more the RDE approach, but not enough to consider doing this>>>>>> proposition to guix upstream, neither to redefine guix-defined home>>>>>> services, so I'm willing to make the change (ie. from>>>>>> XDG_STATE_HOME/log/[].log to (@ (shepherd support) %user-log-dir)/[].log),>>>>>> but would like to gather some feedback before anything.>>>>>>>>>>>> This would be a good opportunity to also finish what I started on>>>>>> msmtp.log and migrate XDG_STATE_HOME from ~/.local/var/lib to the>>>>>> standard ~/.local/state (last XDG base dir revision), and maybe anchor>>>>>> that in a Decision Record for later contributions. WDYT ?>>>>>>>> Hm, I didn't recieve the original message.>>>>>>>>>>>>>> There's also the option not to change anything in guix, but to>>>>> ungexp/gexp the log-file in the service to keep the log in /log/ dir,>>>>> that probably is simpler than I first thought.>>>>>>>>>> We should settle for one approach or the other. Still waiting for some>>>>> input here ;)>>>>>>>> Standardization of log files is a really good idea. Unfortunatelly,>>>> guix services are not flexible enough and we can't provide the function>>>> for generating log-file/dir depending on the use case: For example, I>>>> want to build a dev environment out of home-services and start using>>>> shepherd as docker-compose alternative and it will have a different log>>>> dir.>>>>>> Is it that unflexible?>>>> Yep, it is.>>>>> since it's a file-like that is used, it allows some flexibility that>>> guix uses, for instance :>>>>>> (log-file mcron-configuration-log-file ;string | gexp>>> (thunked)>>> (default>>> (if (mcron-configuration-home-service?>>> this-mcron-configuration)>>> #~(string-append %user-log-dir "/mcron.log")>>> "/var/log/mcron.log")))>>>> You can't do something like this:>>>> (define dev-env>> ;; some pseudo-function somehow providing log-dir value to the>> ;; environment available for guix services>> (with-specific-log-dir "state/logs">> (fold-services>> (list (service mcron-service-type))>> #:target-type home-profile-service-type)))>>>> That's one of the reasons why we need to use features mechanism and rde>> values in rde.>>>>> Can't we inherit from the shepherd service defined in guix, then adapt>>> from there the value of log-file for this kind of flexibility ?>>>> Can you show the example with pseudo-code?>>>> Maybe we can start from something like this? If we can get the gexp out> of there in a procedure, we might have a procedure that could apply to> all configurations (with some more work of course) and just modify the> key #:log-file to put the logs in the right directory. This of course> only applies to records, but maybe it's enough for logs only? Or maybe> it's more simple to keep entering log-files by hand, I a noticed that> the two missing services I have that send logs in the wrong directory> are both from the mail-mcron outdated service.>> (use-modules (guix gexp) (gnu services mcron))>> (define (modify-record rcd field)> (let ((type (record-type-descriptor rcd)))> (when (and (record? rcd)> (member field (record-type-fields type)))> ((record-modifier type field)> rcd> #~(let ((%user-log-dir (string-append (getenv "XDG_STATE_HOME") "/log")))
I'm not sure if it will work, because %user-log-dir will be captured in
lexical scope, where original field value defined.
> #$(((record-accessor type field) rcd) rcd)))))> rcd)>> (modify-record> (mcron-configuration> (home-service? #t))> 'log-file)
However, making a log-file to be a gexp make sense for me.
>>>>>>>> Anyway, I think that /log dir is more apropriate IMO, because it doesn't>>>> matter who manages the service shepherd or whoever.>>>>>> Yes, I agree with this and I think we can enforce that without too much>>> work in the case we can inherit from a shepherd service.>>>>>>>> Writing down the decision would be great, yes.>>>>>> Next task then I guess ;)>>>> (:
--
Best regards,
Andrew Tropin