Make render command recursive #114

Currently it looks like the publish command is recursive, but the render command 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.

Currently it looks like the `publish` command is recursive, but the `render` command 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 dirname or
raco pollen render -r dirname

OK. I’ve added a recursive-rendering option, and you can invoke it with `raco pollen render --recursive dirname` or `raco pollen render -r dirname`

Thanks. This is great. I realize that there are sometimes directories that I would like to have skipped (.git or similar is a common example). I know allowing for this would complicate the render functionality. 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?

Thanks. This is great. I realize that there are sometimes directories that I would like to have skipped (`.git` or similar is a common example). I know allowing for this would complicate the `render` functionality. 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.

But raco pollen render -r will skip directories that are listed in setup:unpublished-path?. So the way to do what you suggest is to override unpublished-path? in your pollen.rkt and then add .git to it.

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.

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. But `raco pollen render -r` will skip directories that are listed in `setup:unpublished-path?`. So the way to do what you suggest is to override `unpublished-path?` in your `pollen.rkt` and then add `.git` to it. 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.

Using 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.

Using `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 render operation 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 .git directory if render descends into it. But it’s cleaner to omit it.) Perhaps the more practical advantage is for subdirectories like old-slow-source-files that 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 reset first.)

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 setup:omit-path?

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 `render` operation 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 `.git` directory if `render` descends into it. But it’s cleaner to omit it.) Perhaps the more practical advantage is for subdirectories like `old-slow-source-files` that 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 reset` first.) 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 `setup:omit-path?`

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:unpublished-path? and setup:unrendered-path? predicates, and maybe have them be the same thing by default?

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:unpublished-path?` and `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.rkt file, but I get the error down below:

(set! setup:omitted-path?
      (lambda (path)
        (define-values (dir name dir?) (split-path))
        (equal? dir ".git")))


pollen.rkt:8:6: set!: cannot mutate module-required identifier
  at: omitted-path?
  in: setup:omitted-path?
  context...:
   /Applications/Racket v6.4/collects/compiler/cm.rkt:346:0: compile-zo*
   /Applications/Racket v6.4/collects/compiler/cm.rkt:561:26
   /Applications/Racket v6.4/collects/compiler/cm.rkt:553:42
   /Applications/Racket v6.4/collects/compiler/cm.rkt:518:0: maybe-compile-zo
   /Applications/Racket v6.4/collects/compiler/cm.rkt:633:2: do-check
   /Applications/Racket v6.4/collects/compiler/cm.rkt:713:4
   /Users/basus/src/pollen/pollen/private/cache-utils.rkt:33:0: path->hash
   /Users/basus/src/pollen/pollen/private/cache-utils.rkt:76:14: temp16
   /Applications/Racket v6.4/collects/file/cache.rkt:63:2: fetch-and-continue
   /Applications/Racket v6.4/collects/racket/contract/private/arrow-val-first.rkt:335:3
   /Users/basus/src/pollen/pollen/private/cache-utils.rkt:67:0: cache-ref!
   /Applications/Racket v6.4/collects/racket/private/more-scheme.rkt:373:13: hash-ref!
   /Users/basus/src/pollen/pollen/cache.rkt:24:4: cached-require-base
   .../more-scheme.rkt:261:28
   /Users/basus/src/pollen/pollen/render.rkt:210:2: get-template
   render-from-source-or-output-path

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.rkt` file, but I get the error down below: ``` scheme (set! setup:omitted-path? (lambda (path) (define-values (dir name dir?) (split-path)) (equal? dir ".git"))) ``` ``` pollen.rkt:8:6: set!: cannot mutate module-required identifier at: omitted-path? in: setup:omitted-path? context...: /Applications/Racket v6.4/collects/compiler/cm.rkt:346:0: compile-zo* /Applications/Racket v6.4/collects/compiler/cm.rkt:561:26 /Applications/Racket v6.4/collects/compiler/cm.rkt:553:42 /Applications/Racket v6.4/collects/compiler/cm.rkt:518:0: maybe-compile-zo /Applications/Racket v6.4/collects/compiler/cm.rkt:633:2: do-check /Applications/Racket v6.4/collects/compiler/cm.rkt:713:4 /Users/basus/src/pollen/pollen/private/cache-utils.rkt:33:0: path->hash /Users/basus/src/pollen/pollen/private/cache-utils.rkt:76:14: temp16 /Applications/Racket v6.4/collects/file/cache.rkt:63:2: fetch-and-continue /Applications/Racket v6.4/collects/racket/contract/private/arrow-val-first.rkt:335:3 /Users/basus/src/pollen/pollen/private/cache-utils.rkt:67:0: cache-ref! /Applications/Racket v6.4/collects/racket/private/more-scheme.rkt:373:13: hash-ref! /Users/basus/src/pollen/pollen/cache.rkt:24:4: cached-require-base .../more-scheme.rkt:261:28 /Users/basus/src/pollen/pollen/render.rkt:210:2: get-template render-from-source-or-output-path ```

The documentation has your answer.

[The documentation has your answer](http://docs.racket-lang.org/pollen/Setup.html).

In your pollen.rkt:

(module setup racket/base
  (provide (all-defined-out))
  (define omitted-path?
      (lambda (path)
        (define-values (dir name dir?) (split-path))
        (equal? dir ".git")))

In your `pollen.rkt`: ``` racket (module setup racket/base (provide (all-defined-out)) (define omitted-path? (lambda (path) (define-values (dir name dir?) (split-path)) (equal? dir ".git"))) ```

On reflection, would it make sense just to add .git to the list of permanently omitted paths (like Racket’s compiled subdirectory and the pollen-cache subdirectory)?

On reflection, would it make sense just to add `.git` to the list of permanently omitted paths (like Racket’s `compiled` subdirectory and the `pollen-cache` subdirectory)?

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 .hg, .svn and CVS while we're at it. We should probably add a line to the docs as well somewhere.

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 `.hg`, `.svn` and `CVS` while 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 setup:extra-path.

But my major counterargument to this line of thinking has been the .htaccess file, 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.

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 `setup:extra-path`. But my major counterargument to this line of thinking has been the `.htaccess` file, 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.

Labels Milestones

Make render command recursive #114