Symbolic link as a source #68

$ ln -s test.pm test.html.pm

$ raco pollen render test.html.pm
Rendering /home/kirrun/proj/test/test.pm /home/kirrun/proj/test/test.html.pm
render: test.pm
render-from-source-or-output-path: contract violation
  expected: pathish?
  given: #f
  in: the 1st argument of
      (->* (pathish?) (#:force boolean?) void?)
  contract from:
      (definition
       render-from-source-or-output-path)
  blaming: <pkgs>/pollen/render.rkt
   (assuming the contract is correct)
  at: <pkgs>/pollen/render.rkt:97.26
  context...:
   /nix/store/dzk1a00x1qv3pbzg3qway2bi7rzmfy5f-racket-6.1.1/share/racket/collects/racket/contract/private/blame.rkt:143:0: raise-blame-error16
   core225
   render-to-file
   unpack62
   loop
   (submod /home/kirrun/.racket/6.1.1/pkgs/pollen/command.rkt raco): [running body]
   /nix/store/dzk1a00x1qv3pbzg3qway2bi7rzmfy5f-racket-6.1.1/share/racket/collects/raco/raco.rkt: [running body]
   /nix/store/dzk1a00x1qv3pbzg3qway2bi7rzmfy5f-racket-6.1.1/share/racket/collects/raco/main.rkt: [running body]

Looks like it dereferences the link and uses test.pm to derive the template name and, obviously, fails, as there is no second-level extension.

For the purpose of deriving the template name the original source name, as was input by user, should be used.

``` Console $ ln -s test.pm test.html.pm $ raco pollen render test.html.pm Rendering /home/kirrun/proj/test/test.pm /home/kirrun/proj/test/test.html.pm render: test.pm render-from-source-or-output-path: contract violation expected: pathish? given: #f in: the 1st argument of (->* (pathish?) (#:force boolean?) void?) contract from: (definition render-from-source-or-output-path) blaming: <pkgs>/pollen/render.rkt (assuming the contract is correct) at: <pkgs>/pollen/render.rkt:97.26 context...: /nix/store/dzk1a00x1qv3pbzg3qway2bi7rzmfy5f-racket-6.1.1/share/racket/collects/racket/contract/private/blame.rkt:143:0: raise-blame-error16 core225 render-to-file unpack62 loop (submod /home/kirrun/.racket/6.1.1/pkgs/pollen/command.rkt raco): [running body] /nix/store/dzk1a00x1qv3pbzg3qway2bi7rzmfy5f-racket-6.1.1/share/racket/collects/raco/raco.rkt: [running body] /nix/store/dzk1a00x1qv3pbzg3qway2bi7rzmfy5f-racket-6.1.1/share/racket/collects/raco/main.rkt: [running body] ``` Looks like it dereferences the link and uses `test.pm` to derive the template name and, obviously, fails, as there is no second-level extension. For the purpose of deriving the template name the original source name, as was input by user, should be used.

Your proposal amounts to a kind of imperative-programming-via-symlink, which is terrifying in its implications ;)

More practically, in this case the expected behavior is obvious, but only because the symlink and its target are in the same directory. What if the symlink were on another file system? What if it were a chain of symlinks with different file extensions along the way? In essence, Pollen would end up with a separate & more subtle implementation of symlinking than the filesystem itself.

Your proposal amounts to a kind of imperative-programming-via-symlink, which is terrifying in its implications ;) More practically, in this case the expected behavior is obvious, but only because the symlink and its target are in the same directory. What if the symlink were on another file system? What if it were a chain of symlinks with different file extensions along the way? In essence, Pollen would end up with a separate & more subtle implementation of symlinking than the filesystem itself.

Wait. What I’m trying to say is that Pollen itself should not care at all whether the file is a symlink or not. When I type raco pollen render test.html.pm I want it to take test.html.pm and turn it into test.html, that’s all. The fact that test.html.pm is a symlink is not Pollen’s business.

Pollen would end up with a separate & more subtle implementation of symlinking than the filesystem itself

I agree that this is bad. But as I said I can’t imagine why would Pollen bother with symlinking at all. I give it the name, it renders it, poof! 🎆

Wait. What I’m trying to say is that Pollen itself _should not care at all_ whether the file is a symlink or not. When I type `raco pollen render test.html.pm` I want it to take `test.html.pm` and turn it into `test.html`, that’s all. The fact that `test.html.pm` is a symlink is not Pollen’s business. > Pollen would end up with a separate & more subtle implementation of symlinking than the filesystem itself I agree that this is bad. But as I said I can’t imagine why would Pollen bother with symlinking at all. I give it the name, it renders it, poof! :fireworks:

OK, I think I understand what you mean: Pollen shouldn’t do any symlink dereferencing. Rather, it should treat the symlink as a real source file and trust that things like template.html and directory-require.rkt are nearby. And that way you can create secondary Pollen project directories that reuse the source from elsewhere (by symlinking). Is that right?

OK, I think I understand what you mean: Pollen shouldn’t do any symlink dereferencing. Rather, it should treat the symlink as a real source file and trust that things like `template.html` and `directory-require.rkt` are nearby. And that way you can create secondary Pollen project directories that reuse the source from elsewhere (by symlinking). Is that right?

Pollen shouldn’t do any symlink dereferencing. Rather, it should treat the symlink as a real source file and trust that things like template.html and directory-require.rkt are nearby.

Exactly.

And that way you can create secondary Pollen project directories that reuse the source from elsewhere (by symlinking).

Well, I wasn’t thinking about “elsewhere,” I just tried this as a work-around for #49 and it didn’t work, so I had to resort to hard-links. I can’t think of a use case for reusing text sources from other projects, but reusing code sources is a pretty common thing.

But the actual problem right now is that Pollen’s current behaviour is just very unnatural.

> Pollen shouldn’t do any symlink dereferencing. Rather, it should treat the symlink as a real source file and trust that things like `template.html` and `directory-require.rkt` are nearby. Exactly. > And that way you can create secondary Pollen project directories that reuse the source from elsewhere (by symlinking). Well, I wasn’t thinking about “elsewhere,” I just tried this as a work-around for #49 and it didn’t work, so I had to resort to _hard_-links. I can’t think of a use case for reusing _text_ sources from other projects, but reusing _code_ sources is a pretty common thing. But the actual problem right now is that Pollen’s current behaviour is just very unnatural.

I can’t think of a use case for reusing text sources from other projects, but reusing code sources is a pretty common thing.

I see what you’re saying, but if we’re talking specifically about code reuse, I don’t want to support techniques (e.g., creative symlinking) that invite developers to circumvent the facilities already present in Racket for doing that. A Pollen file is just an alternate way of writing a Racket source file. Thus, every Pollen source file can be a target of a Racket require or dynamic-require command. Or, going the other way, libraries of Racket functions can be made into locally-installed packages that can be accessed from any Pollen source file (just like the rest of the Racket library).

But beyond that, I’m open to improving how Pollen handles symlinks (I barely use symlinks so I haven’t scrutinized the issue).

> I can’t think of a use case for reusing text sources from other projects, but reusing code sources is a pretty common thing. I see what you’re saying, but if we’re talking specifically about code reuse, I don’t want to support techniques (e.g., creative symlinking) that invite developers to circumvent the facilities already present in Racket for doing that. A Pollen file is just an alternate way of writing a Racket source file. Thus, every Pollen source file can be a target of a Racket `require` or `dynamic-require` command. Or, going the other way, libraries of Racket functions can be made into locally-installed packages that can be accessed from any Pollen source file (just like the rest of the Racket library). But beyond that, I’m open to improving how Pollen handles symlinks (I barely use symlinks so I haven’t scrutinized the issue).

Labels Milestones

Symbolic link as a source #68