render index.ptree with subdirectories changes directory (though not project root) #113

Just a heads up: I had assumed the current directory would be the same as the project root. When the rendered ptree includes files in a sub-directory, the current-directory parameter changes. With or without -s I haven't noticed the current-project-root parameter changing, though.

This matters if you want to use the top-level index.ptree everywhere for navigation, or, e.g., grab a set of dynamic metadata files that live in the project root. You have to use something like (build-path (current-project-root) "file") instead of just "file" everywhere.

Just a heads up: I had assumed the current directory would be the same as the project root. When the rendered ptree includes files in a sub-directory, the `current-directory` parameter changes. With or without `-s` I haven't noticed the `current-project-root` parameter changing, though. This matters if you want to use the top-level `index.ptree` everywhere for navigation, or, _e.g._, grab a set of dynamic metadata files that live in the project root. You have to use something like `(build-path (current-project-root) "file")` instead of just `"file"` everywhere.

If there was something in the documentation that led you to this conclusion, I invite you to suggest a correction.

I think my confusion is related to whether or not rendering a page tree counts as source mode or directory mode. Though neither specifies what assumptions can (should ?) be made about the current directory. I naively assumed current = project root always.

I think my confusion is related to whether or not rendering a page tree counts as _source mode_ or _directory mode_. Though neither specifies what assumptions can (should ?) be made about the current directory. I naively assumed current = project root always.

I naively assumed current = project root always.

IIUC, this is flaky even just because it’s possible to execute raco pollen from a subdirectory [edit; or, really, any directory]. I wouldn’t have expected current-directory to change “mid-flight” as it were, so that part is (very mildly) surprising to me, but I also don’t rely on it anyway for the aforementioned reason.

> I naively assumed current = project root always. IIUC, this is flaky even just because it’s possible to execute `raco pollen` from a subdirectory [edit; or, really, any directory]. I wouldn’t have expected `current-directory` to change “mid-flight” as it were, so that part is (very mildly) surprising to me, but I also don’t rely on it anyway for the aforementioned reason.

I think my confusion is related to whether or not rendering a page tree counts as source mode or directory mode

Docs:

“Source mode: raco pollen render source ... will render only the source paths specified in source ... … If a pagetree file is included in source, all the files it lists will be rendered using the above rules.”

That said, perhaps there are times when current-directory moves in overly mysterious ways. Though to be convinced, I’d need to see an example that gives the wrong result.

Pagenodes in a pagetree are treated as relative to that pagetree, so when doing operations on the pagetree (for instance, converting the pagenodes to paths), current-directory is moved to match the pagetree itself.

> I think my confusion is related to whether or not rendering a page tree counts as source mode or directory mode [Docs:](https://docs.racket-lang.org/pollen/raco-pollen.html#%28part._raco_pollen_render%29) “Source mode: `raco pollen render source ...` will render only the source paths specified in `source ...` … **If a pagetree file is included in source, all the files it lists will be rendered using the above rules.**” That said, perhaps there are times when `current-directory` moves in overly mysterious ways. Though to be convinced, I’d need to see an example that gives the wrong result. Pagenodes in a pagetree are treated as relative to that pagetree, so when doing operations on the pagetree (for instance, converting the pagenodes to paths), `current-directory` is moved to match the pagetree itself.

I think probably this can be closed--I was simultaneously bit by the fact that parallel mode uses places which don't inherit (current-directory), and that was mucking with my setting it before calling the internal raco pollen using raco/all-tools.

Anyway, the solution for me so far has been to use (current-project-root) and assume pollen runs in the source directory on the index.ptree (at least for rendering). Since I control when and where the commands run in my case, it's not a big deal.

It's possible define-runtime-path would help, too. @otherjoel I'm curious how you avoid depending on (current-directory) in the "sub-directory files rely on stuff higher up" cases--are you using similar workarounds, or designing so this doesn't happen?

I think probably this can be closed--I was simultaneously bit by the fact that parallel mode uses places which don't inherit `(current-directory)`, and that was mucking with my setting it before calling the internal `raco pollen` using `raco/all-tools`. Anyway, the solution for me so far has been to use `(current-project-root)` and assume pollen runs in the source directory on the `index.ptree` (at least for rendering). Since I control when and where the commands run in my case, it's not a big deal. It's possible `define-runtime-path` would help, too. @otherjoel I'm curious how you avoid depending on `(current-directory)` in the "sub-directory files rely on stuff higher up" cases--are you using similar workarounds, or designing so this doesn't happen?

@otherjoel I'm curious how you avoid depending on (current-directory) in the "sub-directory files rely on stuff higher up" cases--are you using similar workarounds, or designing so this doesn't happen?

In general I try to ensure that anything a Pollen source file needs is provided in some form by pollen.rkt. If files are going to need to access or specify something in terms of a relative path, I usually create a function that safely builds a correct path for that thing. Or just hide that logic inside a function that grabs the file and returns the thing.

> @otherjoel I'm curious how you avoid depending on (current-directory) in the "sub-directory files rely on stuff higher up" cases--are you using similar workarounds, or designing so this doesn't happen? In general I try to ensure that anything a Pollen source file needs is `provide`d in some form by `pollen.rkt`. If files are going to need to access or specify something in terms of a relative path, I usually create a function that safely builds a correct path for that thing. Or just hide that logic inside a function that grabs the file and returns the thing.

With or without -s I haven't noticed the current-project-root parameter changing, though.

PS I’m supposing you already know about the --recursive switch, which is like -s but does change current-project-root as it moves among subdirectories.

> With or without -s I haven't noticed the current-project-root parameter changing, though. PS I’m supposing you already know about the `--recursive` switch, which is like `-s` but *does* change `current-project-root` as it moves among subdirectories.

I ended up finding a way to use more (require) and (define-runtime-path, and avoid all of this, I think

I ended up finding a way to use more `(require)` and `(define-runtime-path`, and avoid all of this, I think

Labels Milestones

render index.ptree with subdirectories changes directory (though not project root) #113