bug#52808: Guix home should not assume that all targets are dot files
On 2021-12-26 12:17, Nick Zalutskiy wrote:
> The following configuration results in a `~/.run` symlink being
> created. My expectation is that a `~/run` symlink is created
> instead. (ie. not a dotfile)
Some how I missed it and not documented home-files-service-type in the
manual, I'll add it soon. Thank you for mentioning it. It should break
this expectation :)
>> (home-environment
>> (services
>> (list (service
>> home-bash-service-type
>> (home-bash-configuration
>> (guix-defaults? #t)))
>> (simple-service 'my-files
>> home-files-service-type
>> `(("run" ,(local-file "run")))
>
> This applies to all other targets. My expectation is that the
> configuration should expect the exact target and not make an
> assumption that all targets are hidden files, since that allows for
> more utility:
>
>> (home-environment
>> (services
>> (list (service
>> home-bash-service-type
>> (home-bash-configuration
>> (guix-defaults? #t)))
>> (simple-service 'config-files
>> home-files-service-type
>> `(("run" ,(local-file "run"))
>> ("README.txt" ,(local-file "README.txt"))
>> (".config/guix/channels.scm" ,(local-file "config/guix
>> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
>> (".vimrc" ,(local-file "vimrc"))
>> (".gitconfig" ,(local-file "gitconfig")))
>
> Thank you,
>
> -Nick
It's intentional and is a part of a design decision:
For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
chans.scm goes not to ~/.config/guix/channels.scm, but to
$XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
from ~/.config, absent dot should partially break this expectation.
It's a bad practice to use something without "config/..." prefix and
generally it should be avoided, it still possible to use something
different in rare use-cases, for example for zsh: ("zshenv"
,zshenv-file-like-here), because it's hard to implement the lookup for
initial configuration file other way for shells.
You can elaborate more on what you try to achieve and I can try to give
you a recommendation how to implement it.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
Hi Andrew,
I have files that I consider my "home configuration" that do not go into
.config or any other dot dir. For example, I place an executable shell script
to automate some tasks in the home dir of every machine. The script is called
`run` all I want to do is place it as ~/run Placing this file in PATH is not
appropriate in my case.
The current design makes this impossible to achieve it seems. I just live with
`~/.run` now, but it is ergonomically cumbersome for reasons that are too
obscure to go into.
Why not, just as an example:
`("$XDG_CONFIG_DIR/guix/channels.scm" ,(local-file "./chans.scm"))`
Which is explicit and sets the right expectation without any other context. The
implicit heuristics around how the input is interpreted are an unfortunate
design decision in my opinion, they make a simple tool more difficult to use.
Having said all that, the documentation helps a lot. Thank you for the patch!
Best,
-Nick
On Fri, Jan 28, 2022, at 5:51 AM, Andrew Tropin wrote:
> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>
>> The following configuration results in a `~/.run` symlink being
>> created. My expectation is that a `~/run` symlink is created
>> instead. (ie. not a dotfile)
>
> Some how I missed it and not documented home-files-service-type in the
> manual, I'll add it soon. Thank you for mentioning it. It should break
> this expectation :)
>
>>> (home-environment
>>> (services
>>> (list (service
>>> home-bash-service-type
>>> (home-bash-configuration
>>> (guix-defaults? #t)))
>>> (simple-service 'my-files
>>> home-files-service-type
>>> `(("run" ,(local-file "run")))
>>
>> This applies to all other targets. My expectation is that the
>> configuration should expect the exact target and not make an
>> assumption that all targets are hidden files, since that allows for
>> more utility:
>>
>>> (home-environment
>>> (services
>>> (list (service
>>> home-bash-service-type
>>> (home-bash-configuration
>>> (guix-defaults? #t)))
>>> (simple-service 'config-files
>>> home-files-service-type
>>> `(("run" ,(local-file "run"))
>>> ("README.txt" ,(local-file "README.txt"))
>>> (".config/guix/channels.scm" ,(local-file "config/guix
>>> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
>>> (".vimrc" ,(local-file "vimrc"))
>>> (".gitconfig" ,(local-file "gitconfig")))
>>
>> Thank you,
>>
>> -Nick
>
> It's intentional and is a part of a design decision:
>
> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
> chans.scm goes not to ~/.config/guix/channels.scm, but to
> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
> from ~/.config, absent dot should partially break this expectation.
>
> It's a bad practice to use something without "config/..." prefix and
> generally it should be avoided, it still possible to use something
> different in rare use-cases, for example for zsh: ("zshenv"
> ,zshenv-file-like-here), because it's hard to implement the lookup for
> initial configuration file other way for shells.
>
> You can elaborate more on what you try to achieve and I can try to give
> you a recommendation how to implement it.
>
> --
> Best regards,
> Andrew Tropin
>
> Attachments:
> * signature.asc
bug#52808: Guix home should not assume that all targets are dot files
On 2022-01-28 08:33, Nick Zalutskiy wrote:
> Hi Andrew,
>
> I have files that I consider my "home configuration" that do not go
> into .config or any other dot dir. For example, I place an executable
> shell script to automate some tasks in the home dir of every
> machine. The script is called `run` all I want to do is place it as
> ~/run Placing this file in PATH is not appropriate in my case.
>
> The current design makes this impossible to achieve it seems. I just
> live with `~/.run` now, but it is ergonomically cumbersome for reasons
> that are too obscure to go into.
You can extend activation home service with a script, which will symlink
a necessary executable to ~/run.
>
> Why not, just as an example:
>
> `("$XDG_CONFIG_DIR/guix/channels.scm" ,(local-file "./chans.scm"))`
The $XDG_CONFIG_DIR is not know at build-time, so it won't work.
Creating a literal files/$XDG_CONFIG_DIR directory is possible, but also
not ideal. However the idea sounds not that bad.
>
> Which is explicit and sets the right expectation without any other
> context. The implicit heuristics around how the input is interpreted
> are an unfortunate design decision in my opinion, they make a simple
> tool more difficult to use.
It's partially intentional to force users to stick to XDG specification
for config files and minimize the usage of dotfiles in $HOME. The
binaries are inteded to go to profile/bin or other directory on the
path. But it always possible to bypass this decision by directly
extending home-service-type or home-activation-service-type.
I see what you mean about implicit heuristics and mostly agree.
>
> Having said all that, the documentation helps a lot. Thank you for the
> patch!
Sure ;)
>
> Best,
>
> -Nick
>
> On Fri, Jan 28, 2022, at 5:51 AM, Andrew Tropin wrote:
>> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>>
>>> The following configuration results in a `~/.run` symlink being
>>> created. My expectation is that a `~/run` symlink is created
>>> instead. (ie. not a dotfile)
>>
>> Some how I missed it and not documented home-files-service-type in the
>> manual, I'll add it soon. Thank you for mentioning it. It should break
>> this expectation :)
>>
(home-environment
(services
(list (service
home-bash-service-type
(home-bash-configuration
(guix-defaults? #t)))
(simple-service 'my-files
home-files-service-type
`(("run" ,(local-file "run")))
>>>
>>> This applies to all other targets. My expectation is that the
>>> configuration should expect the exact target and not make an
>>> assumption that all targets are hidden files, since that allows for
>>> more utility:
>>>
(home-environment
(services
(list (service
home-bash-service-type
(home-bash-configuration
(guix-defaults? #t)))
(simple-service 'config-files
home-files-service-type
`(("run" ,(local-file "run"))
("README.txt" ,(local-file "README.txt"))
(".config/guix/channels.scm" ,(local-file "config/guix
(".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
(".vimrc" ,(local-file "vimrc"))
(".gitconfig" ,(local-file "gitconfig")))
>>>
>>> Thank you,
>>>
>>> -Nick
>>
>> It's intentional and is a part of a design decision:
>>
>> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
>> chans.scm goes not to ~/.config/guix/channels.scm, but to
>> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
>> from ~/.config, absent dot should partially break this expectation.
>>
>> It's a bad practice to use something without "config/..." prefix and
>> generally it should be avoided, it still possible to use something
>> different in rare use-cases, for example for zsh: ("zshenv"
>> ,zshenv-file-like-here), because it's hard to implement the lookup for
>> initial configuration file other way for shells.
>>
>> You can elaborate more on what you try to achieve and I can try to give
>> you a recommendation how to implement it.
>>
>> --
>> Best regards,
>> Andrew Tropin
>>
>> Attachments:
>> * signature.asc
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52585: lualatex: Unexpected non-option argument(s): lualatex.fmt
Hello, Em segunda-feira, 24 de janeiro de 2022, às 11:11:25 -03, Pāladhammika escreveu: > Hello, > > Yes! I also noticed. Can now upgrade to texlive2021 with no issues > building my documents. Thanks for your effort and support. Awesome! Ricardo Wurmus has been fixing some issues with TeX Live in Guix lately. One of his patches must have fixed your problem. I’m closing the bug now. -- Thanks, Thiago
