shared use of the `compiled` subdirectory

[Matthew Butterick]

In `pollen` I create what are essentially compile caches and store them in subdirectories called `pollen-cache`. When it's time to invalidate caches for the project, I delete all the `pollen-cache` subdirectories and all the Racket-created `compiled` subdirectories.

But it has occurred to me that I wouldn't lose anything by moving every `pollen-cache` subdirectory into the nearby `compiled` directory.

What is the thinking (if any) on sharing the `compiled` subdirectories?

One point of view is that these folders should be private to the Racket language, forever.

Another view is that if one is making a Racket-implemented DSL that keeps a compile cache, it should live in the same `compiled` subdir (on the idea that users are already, say, setting up `.gitignore` to ignore those subdirs.) This would be consistent with the general orientation toward letting Racket-implemented DSLs reuse the Racket language ecosystem. Having multiple conventions for where to store compile caches is unnecessary.

A third view is that the `compiled` subdir should be open to all who want to use it, but that there should be a convention of each package making a subdirectory therein, so that the `racket` caches don't mess with `pollen` caches and vice versa and so on (which would be more of a social convention than technical convention)

[Matthew Flatt]

At Sun, 20 Nov 2016 17:31:35 -0800 (PST), Matthew Butterick wrote:
> In `pollen` I create what are essentially compile caches and store them in
> subdirectories called `pollen-cache`. When it's time to invalidate caches
> for the project, I delete all the `pollen-cache` subdirectories and all the
> Racket-created `compiled` subdirectories.
>
> But it has occurred to me that I wouldn't lose anything by moving every
> `pollen-cache` subdirectory into the nearby `compiled` directory.
>

> *What is the thinking (if any) on sharing the `compiled` subdirectories?*

>
> One point of view is that these folders should be private to the Racket
> language, forever.
>
> Another view is that if one is making a Racket-implemented DSL that keeps a
> compile cache, it should live in the same `compiled` subdir (on the idea
> that users are already, say, setting up `.gitignore` to ignore those
> subdirs.) This would be consistent with the general orientation toward
> letting Racket-implemented DSLs reuse the Racket language ecosystem. Having
> multiple conventions for where to store compile caches is unnecessary.

This sounds right to me. I have various one-off tools that write files
into "compiled" --- mostly for the ".gitignore" reason.

> A third view is that the `compiled` subdir should be open to all who want
> to use it, but that there should be a convention of each package making a
> subdirectory therein, so that the `racket` caches don't mess with `pollen`
> caches and vice versa and so on (which would be more of a social convention
> than technical convention)

This sounds like a good direction. Maybe a convention could be based on
file extensions and/or subdirectories, since tools like `raco make` and
`raco setup` will write only ".zo" and ".dep" files.

[Robby Findler]

On Sun, Nov 20, 2016 at 7:37 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
>> A third view is that the `compiled` subdir should be open to all who want
>> to use it, but that there should be a convention of each package making a
>> subdirectory therein, so that the `racket` caches don't mess with `pollen`
>> caches and vice versa and so on (which would be more of a social convention
>> than technical convention)
>
> This sounds like a good direction. Maybe a convention could be based on
> file extensions and/or subdirectories, since tools like `raco make` and
> `raco setup` will write only ".zo" and ".dep" files.

Using ring-0 pkg names as the names of those directories sounds right
to me. (DrRacket already uses this convention (but I think its use
predates pkgs).)

Robby