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