Make render command recursive
Closedopened 7 years ago by basus · 12 comments
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Currently it looks like the
publishcommand is recursive, but the
rendercommand is not. So if I have a hierarchy of directories containing pollen source, I need to manually enter each directory and run
raco pollen render. It would be nice to just have to run that command at the top-most directory and have it recursively compile down.
OK. I’ve added a recursive-rendering option, and you can invoke it with
raco pollen render --recursive dirnameor
raco pollen render -r dirname
Thanks. This is great. I realize that there are sometimes directories that I would like to have skipped (
.gitor similar is a common example). I know allowing for this would complicate the
renderfunctionality. Do you see Pollen growing such complex functionality, or should users use Pollen as library and write their custom code to handle more complex uses?
I’ve vacillated on whether to automatically exclude dot-prefixed files from Pollen operations. I think the answer should be no, because that’s more consistent with Pollen’s “shadow government” approach to things.
raco pollen render -rwill skip directories that are listed in
setup:unpublished-path?. So the way to do what you suggest is to override
pollen.rktand then add
Having said that, I see that I didn’t mention it in the docs, but now I’m also wondering if co-opting
setup:unpublished-path?is the right idea. Having an entirely separate setting seems cumbersome, however.
setup:unpublished-path?seems fine for directories that you don't want to render and don't want to publish. So it work for things like
.git. However, I can imagine having asset directories (images, etc.) that don't need to be rendered, but need to be published.
Rendering and publishing work slightly differently.
Rendering is opt-in: a file can only be rendered if it has a Pollen source file associated with it. In that sense, the
renderoperation is self-limiting. If you try to render an asset directory with static files in it, nothing will happen. (For that reason, nothing bad is likely to happen to your
renderdescends into it. But it’s cleaner to omit it.) Perhaps the more practical advantage is for subdirectories like
old-slow-source-filesthat you might want to keep in the repo, but not actually render every time. (BTW during a render, Pollen will rely on cached copies whenever possible (unless you do a
raco pollen resetfirst.)
Publishing, by contrast, is opt-out: it copies the entire directory, and then deletes stuff from the duplicate, using
setup:unpublished-path?(and a few other tests that remove Pollen- and Racket-related files).
Maybe both ideas can be captured by the more generic-sounding
After reading your description, it seems like
setup:unpublished-path?might be fine. I'm trying to think of a case where Pollen might want to render a file, but we don't want it to. But I don't think such accidental renders are very likely to happen in practice. There might be a case where you'd want to render something, but not publish it, but again, I don't see that happening very much in practice. To be very explicit, we might want separate
setup:unrendered-path?predicates, and maybe have them be the same thing by default?
This is more of a basic Racket question, but I'm trying to figure out how to actually set the
setup:unpublished-path?variable? I'm trying to use the following snippet in my
pollen.rktfile, but I get the error down below:
The documentation has your answer.
On reflection, would it make sense just to add
.gitto the list of permanently omitted paths (like Racket’s
compiledsubdirectory and the
I'm usually against programs having implicit behaviors, but in this case, I think it's the right thing to do. Might as well as
CVSwhile we're at it. We should probably add a line to the docs as well somewhere.
On even more reflection, I’m now reconsidering, a tiny bit, the hidden-file policy. Things like
.DS_Store(on OS X) don’t need to be copied. Hiding, after all, is how a file signals to the world “hey, I’m probably not something you want to handle by default.” Also, one could always add hidden files back with
But my major counterargument to this line of thinking has been the
.htaccessfile, which is (annoyingly) hidden yet totally essential.
Still, I think there’s a principled middle position, which is that source-control directories are “meta-directories” in a way that other hidden files are not. If someone is bothered by
.DS_Store, they can omit it manually.
So for the time being, I’ve convinced myself this is fine, but this note will remain for future generations.