Great to see this, have been waiting for proper file support in flake-parts for a long time. In the past, I resorted to using symbolic links combined with a shell hook, but this looks much better. The last thing missing for me would be support for directories, the documentation says it‘s currently missing. Any plans on adding this in the short term?
You’re welcome!
support for directories
Let’s make sure we’re on the same page; file paths can be nested arbitrarily:
[
{
path_ = "docs/examples.md";
drv =
pkgs.writeText "examples.md"
# markdown
''
Example A...
'';
}
]
For me it‘s about a derivation that downloads a folder with test files from some server. I basically would like to replace this derivation with your flake-parts module: arguebuf-python/flake.nix at 5b719468b6f06b029636509141bee913dfa15a42 · recap-utr/arguebuf-python · GitHub
And you want that folder to be Git tracked in your repo?
No I want it to be created when running the tests and entering a dev shell. Could be that I completely missed the point about your module and my use case is not even covered by it
For that use case I think two features are missing. Support for out paths that are directories is one. The other is disabling files checks globally and/or per file. PR welcome
Do you copy them out the store into the main repo?
I think I’m missing a real example in the docs.
Do you copy them out the store into the main repo?
Yes. Did you read the options at files - flake-parts ?
I’ve been using mighthyiam/files
a lot in dendrix. The community/discovered json files are generated with it - and later they are used for the search UI and automatically included in PRs by a nightly update-sources
github action (gh-actions also generated by files
, based your code). So, thanks a lot for it, @mightyiam.
@fzakaria there are some real world examples in the mightyiam/files
repo, since it dogfoods itself. At least that’s how I learned to use it (and stole gh-actions generators).
My mind is toying with the following idea based on mighthyiam/files
.
Maybe I’ll try to implement this later today:
We could have a flake.nix
file writer:
It would define module options for the flake file structure: description
, inputs.{url, flake, inputs._name_.follows}
, nixConfig
except for outputs
(since it is a function - non serializable to string) but this is a good thing since it could hardcode outputs
on the generated file to always be: outputs = inputs: import ./outputs.nix inputs;
this way the flake.nix keeps clean (no nix logic, just define dependencies and nixConfig)
having this flake.nix generator (from module options) would allow any module to specify an input it will need to work. and the input would be aggregated and included in the generated flake.nix file.
We can also have dependency flatenning (.follows) either automatic or opt-in.
Haha, will experiment on it later today.
I never meant for that to happen…
Here is it: