Allow other freshrc files to be sourced in freshrc files.

[twe4ked]

# .freshrc
fresh twe4ked/dotfiles fresh/zsh-syntax-highlighting.freshrc --freshrc

…could be used to pull in this zsh syntax highlighting freshrc:

# fresh/zsh-syntax-highlighting.freshrc
fresh zsh-users/zsh-syntax-highlighting zsh-syntax-highlighting.zsh --file=vendor/zsh-syntax-highlighting.zsh
fresh zsh-users/zsh-syntax-highlighting highlighters/main/main-highlighter.zsh --file=vendor/highlighters/main/main-highlighter.zsh
fresh zsh-users/zsh-syntax-highlighting highlighters/brackets/brackets-highlighter.zsh --file=vendor/highlighters/brackets/brackets-highlighter.zsh
fresh zsh/zsh-syntax-highlighting.zsh

fresh will resolve local files (fresh zsh/zsh-syntax-highlighting.zsh) based on where the freshrc is sourced from.

The .freshrc extention would be optional.

:metal:

[twe4ked]

When we are pulling in a .freshrc from a remote repo we want to treat any local file references are remote references. If we do #56 first this might become easier.

[pvdissel]

I was just looking for this feature :)

I use freshshell in the following way:

• I've a public dotfiles repo with all my publish stuff (duh)
• and I've a private dotfiles repo, which currently pulls down everything from my public repo and adds some private details in the mix Meaning, I mostly duplicate my freshrc file with the public dotfiles freshrc file in my private dotfiles to fetch my public dotfiles stuff.

I don't understand the description of #56 fully so don't know if it would help me, but #47 is exactly what I was looking for.

Would love to see this implemented. Any plans to implement this?

As far as I can see in the bin/fresh file, what should be done to implement this, is:

• extend _run_dsl() to support giving a specific freshrc file as argument
• extend _parse_fresh_dsl_args() to support the --freshrc argument
• extend_dsl_install_fresh() to support the --freshrc mode -- where _dsl_install_fresh() checks out the additional gitrepo to get access to it's freshrc file and content of the rest of the repo where that freshrc file is based on -- then, the _run_dsl() should be recursively called for each --freshrc line

Is that about correct? Maybe I can start/help implementing it. I see you have a set of tests, so I will try to make a few tests first. (first time unit testing shell scripts, but there's a first time for everything :))

[jasoncodes]

Additional requirement: Multiple fresh_after_build callbacks defined across freshrc files really should work as well.

[jasoncodes]

@pvdissel Oops. I missed this comment. Sorry.

Your steps on how to implement this closely match what I was thinking. I’m not sure _dsl_install_fresh should need to be changed though. None of the _dsl_*_fresh methods should need to directly know about --freshrc.

_parse_fresh_dsl_args should probably do the repo fetch and recursing into the nested freshrc file. It would set a variable which _parse_fresh_dsl_args within the nested _run_dsl call would use to know what their “local” repo name is. This variable would be restored to its previous value after the nested freshrc is parsed.

[jasoncodes]

To support a fresh_after_build per sourced freshrc, we can use declare -f fresh_after_build to retrieve the function definition and redefine it for later with a unique sequence number.

[solomonjames]

Has there been any update or branch started for this issue?

[jasoncodes]

@solomonjames Not that I’m aware of.

[solomonjames]

@jasoncodes if I wanted to work on this, where would you suggest starting?

[jasoncodes]

@solomonjames I would start with a few test cases and push them up onto a branch to make sure we all agree on how it should behave. After that, I think the comments in this thread are good indication of how I’d go about implementing it.

More than happy to answer any questions you may have. Thanks for your interest in this.

[mikelococo]

Two use-cases where folks frequently want this are:

• Host-specific behavior: Do foo on my machine at work, but bar on my home file-server.
• Public/Private repos: One wants to publish their dotfiles, but keep some information in a private-repo.

It's worth remembering as a workaround that freshrc files are executable bash scripts, not just a data format:

# Choose a version of a file based on hostname
if [[ `hostname` == "work-machine" ]]; then
    fresh ssh://username@example.com/~/dotfiles-work.git gitconfig --file=~/.gitconfig
else
    fresh ssh://username@home.lan/~/dotfiles-home.git gitconfig --file=~/.gitconfig
fi

# Building a file from snippets in two repositories
fresh 'zshrc-common/*.zsh' --file=~/.zshrc
if [[ `hostname` == "work-machine" ]]; then
   fresh ssh://username@example.com/~/dotfiles-work.git 'zshrc-work/*.zsh' --file=~/.zshrc
fi

This isn't ideal, because each repository isn't self-contained and can't be easily composed. Instead, all the intelligence must be encoded in a "master" freshrc which simply pulls file-content out of remote repositories that likely have no freshrc of their own. Still, it's flexible enough to address several use-cases and is relatively simple to use.

[jamesottaway]

TIL about this issue, which is the same pain point I've had recently while trying to share large chunks of a single .freshrc with my coworkers. Thanks all!