Environmental variables are cached by Pollen #86

Closed
opened 9 years ago by fasiha · 5 comments
fasiha commented 9 years ago (Migrated from github.com)

Borrowing a page from the web development crowd, I'm using an environmental variable called TESTING to control behavior of my Pollen build. When I'm testing on my local machine, I want the rendered output to use a local copy of MathJax, e.g., but for production, I want it to point to the CDN. If my Pollen markup file contains ◊(define-meta development (getenv "TESTING")), then my template can select-from-metas and detect when I run $ TESTING=1 raco pollen render file.html vs just raco pollen ….

However, for this to work in practice, I have to delete the pollen-cache directory. It would appear that the result of getenv is cached and reused.

I'm tempted to disable caching (I saw how to in one of these issues using a config module) because Pollen's CPU time is lower after I delete cache than if I don't (180 vs 260), but I thought I should send a note and see if there was a better way forward.

Borrowing a page from the web development crowd, I'm using an environmental variable called `TESTING` to control behavior of my Pollen build. When I'm testing on my local machine, I want the rendered output to use a local copy of MathJax, e.g., but for production, I want it to point to the CDN. If my Pollen markup file contains `◊(define-meta development (getenv "TESTING"))`, then my template can `select-from-metas` and detect when I run `$ TESTING=1 raco pollen render file.html` vs just `raco pollen …`. However, for this to work in practice, I have to delete the pollen-cache directory. It would appear that the result of `getenv` is cached and reused. I'm tempted to disable caching (I saw how to in one of these issues using a config module) because Pollen's CPU time is lower after I delete cache than if I don't (180 vs 260), but I thought I should send a note and see if there was a better way forward.
mbutterick commented 9 years ago (Migrated from github.com)

Yes, disabling the compile cache in your pollen.rkt will work:

(module config racket/base
  (provide (all-defined-out))
  (define compile-cache-active #f))

I’ve also just pushed an update that makes the cache look for a POLLEN environment variable (= more general designator than TESTING). So this:

$ POLLEN=1 raco pollen render file.html

will not compile the same way as this:

$ raco pollen render file.html
Yes, disabling the compile cache in your `pollen.rkt` will work: ``` racket (module config racket/base (provide (all-defined-out)) (define compile-cache-active #f)) ``` I’ve also just pushed an update that makes the cache look for a `POLLEN` environment variable (= more general designator than `TESTING`). So this: ``` $ POLLEN=1 raco pollen render file.html ``` will not compile the same way as this: ``` $ raco pollen render file.html ```
mbutterick commented 9 years ago (Migrated from github.com)

Meaning, if you use the POLLEN environment variable, you needn’t disable the cache.

Meaning, if you use the `POLLEN` environment variable, you needn’t disable the cache.
mbutterick commented 9 years ago (Migrated from github.com)

As for all the other environment variables … this runs into the general problem of cache invalidation. You can always create a new dependency from afar. The only way for the Pollen cache to be certain that something hasn’t changed is to compile afresh every time (which of course would be the equivalent of not caching at all).

So for the cache to be useful, there has to be a limit on the horizon of dependency checking. For those who need true unfettered dynamism, disabling the cache is the solution.

BTW there is also a render cache, so the whole cache-disabling config would be this:

(module config racket/base
  (provide (all-defined-out))
  (define compile-cache-active #f)
  (define render-cache-active #f))
As for all the other environment variables … this runs into the general problem of cache invalidation. You can always create a new dependency from afar. The only way for the Pollen cache to be certain that something hasn’t changed is to compile afresh every time (which of course would be the equivalent of not caching at all). So for the cache to be useful, there has to be a limit on the horizon of dependency checking. For those who need true unfettered dynamism, disabling the cache is the solution. BTW there is also a render cache, so the whole cache-disabling config would be this: ``` racket (module config racket/base (provide (all-defined-out)) (define compile-cache-active #f) (define render-cache-active #f)) ```
fasiha commented 9 years ago (Migrated from github.com)

Most awesome, thank you good sir 👍!

Most awesome, thank you good sir 👍!
mbutterick commented 9 years ago (Migrated from github.com)

I use this a lot now. Good idea!

I use this a lot now. Good idea!
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mbutterick/pollen#86
Loading…
There is no content yet.