Compiling website in other folder

[tobiasBora]

Hello,

I'm discovering this great tool, but I've an issue. I'd like to write a script that compiles a website that is not in the current folder (I'd like the current folder to contain the final website, usually in _site. Indeed, because I use nix, the source folder is write-only.

Would it be possible to compile with something like:

./mysite build --src /my/source/folder --dest ./

Or if it's already possible to do that with some workaround, could you describe/document them please?

[pcoves]

Does https://robertwpearce.com/hakyll-pt-1-setup-and-initial-customization.html#configuration-rules help in any way?

Using Configuration you can tell Hakyll where to fetch files and where to output them.

[tobiasBora]

I guess it helps a bit, but the problem is that each time we want to compile the website to another directory, we need to rebuild the Haskell code. Of course, we can ask the user to manually parse the command line arguments to fill the configuration, but I'd say it would be better if this could be included directly in the default `hakyll` command (it already parses the arguments to check which function to run). I can try to do a PR when I've some time if you like.

[pcoves]

Well, I'm simply passing by and far from being an expert when it comes to both haskell and hakyll so I'll let the maintainers decide if it's worth the effort.

Keep in mind that if changing the directory is not a common event it's easier to recompile.

Also, parsing the command line myself and building the Configuration would be my preferred way.

[Minoru]

@tobiasBora As a middle ground, you can supply the path via an environment variable, which you read at the start of main and put into a Configuration which is then passed into hakyllWith.

[Radvendii]

+1 to this issue.
It would be useful to me to be able to specify the source directory at the command line. I'm writing a nix flake that wraps hakyll (https://github.com/radvendii/hakyll-flake-gen), and I'd like to use the same executable, but with different source directories depending on the context. (current directory during the build process, but 'website-src' directory when it's run as "nix run . -- watch")

And I would rather not rely on the user setting their Configuration correctly

[Minoru]

@Radvendii I never used Nix flakes. Looks like a wrapper over the user's Cabal project? Can you explain why a user would want to build from different directories depending on the context?

[tobiasBora]

A Nix Flake is a kind of recipe that tells you how to compile a given project and package it for the Nix package manager. It is particularly nice to use: for example you can compile and run a project using a single line:

nix run github:myuser/myproject -- watch

You don't even need to clone locally the project (of course you can if you plan to develop locally), or install any dependency (except of course the Nix package manager, with Flake support): everything is done automatically. It is also extremely reproducible (Flake pins all dependencies), and it can be particularly useful if you want a common environment between all developpers, or if you want to use it to deploy your website automatically using a CI solution.

So if I understand correctly (correct me if I'm wrong), Radvendii is building a kind of library that allows you to automatically compile and package for Nix a Hakyll website in a few lines (and I do think it is useful, I came up with writting the same kind of code myself).

Concerning the fact that Radvendii wants to compile from different directories depending on the context, the thing is that Nix can also be used during development (if you don't go into development mode, you will not be able to benefit from caching between builds). Therefore, in development mode, you usually want to compile the current directory normally. However, when you compile an external project (for example using nix build github:myuser/myproject), the source will be automatically copied into a write-only location in the /nix/store, so you want to be able to specify where is located this folder. Because you can't do that currently, I guess the only solution is to do a full copy (or maybe a link will be enough) of the website in the build directory, and hardcode it in site.hs but it is quite dirty.

Also, it makes a lot of sense to separate the executable from the website-src, since you could use a single executable to create many different website (a bit like you just have one executable in gohugo that can be used to create many other websites). It also make sense when you trust the coder of the executable, but not the coder of a particular website.

@Radvendii : do you plan to also put a way to only compile the executable, but let the user use it as he want: either in another flake, or use it directly if the user do not plan to package its website but plans to use the executable of someone else? Also, sorry for answering at your place, feel free to correct me if I did not get your point.

[Minoru]

Okay, I think I understand the use-case now, but I still disagree that these options make sense for Hakyll. The comparison to Hugo is misguided: Hugo follows a "convention over configuration" pattern, i.e. it has a fixed layout which all sites follow. That's what enables Hugo to have a single binary which is configured at runtime (via a file). Hakyll, on the other hand, is first and foremost a library, and each site is a snowflake, with its own layout and configuration. So no, in general it doesn't make that much sense to separate the executable from the website-src. They're intertwined.

Specifically, every site has its own deployment command, which obviously will mention the destination directory (the default "_site" or whatever the user specified in Configuration.destinationDirectory). If Hakyll were to provide an option to change the destination dir, how would it update the deployment command to match? Would we have to introduce a placeholder that gets replaced by a path to the destination dir? If we do, how does that help hakyll-flake-gen? Most sites would probably never adopt the placeholder because they work fine without, and so hakyll-flake-gen would only work with sites that did adopt the placeholder — but those sites could just as well modify Hakyll's parser to provide the necessary options.

[Radvendii]

Hey, sorry for the delay.
TL;DR of this comment: I don't think I actually need this feature in the end.

@tobiasBora has most of it right, but it's actually kind of the opposite. Nix indeed copies the source directory into a /nix/store/... directory when building, but it actually puts us in that directory (and we have write privileges), so that kind of compilation goes off without a hitch. The problem is I want to be able to run "nix run . -- watch", and this is run from the current directory, which is not necessarily the source directory. In my case I have the following directory structure:

.
├── builder
         ├── package.yaml
         └── site.hs
├── _cache
├── flake.lock
├── flake.nix
├── result
├── _site
└── src
      ├── blog
      ├── index.md
      └── ...

I've realized though, two things:

1. Having the ability to specify the source at the command line doesn't help as much as I hoped (because the nix flake doesn't actually know the name of the directory, it just has a path to the copy of that directory)
2. I can work within the hakyll paradigm by having the user only specify the top level directory, and expect them to arrange any sub-directory stuff with destinationDirectory themselves. I didn't know about this when I started designing the project, so I basically tried to build that functionality into my own design, but if Hakyll takes care of it, I can just let Hakyll take care of it.

@tobiasBora as to your question: Yes, the function provides two packages: "builder" (which is just the compiled haskell / hakyll code) and "website", which then also uses the builder to compile the site. It should all be explained in the readme. Also, if you have any suggestions for the project based on your experience, I'm all ears.

@Minoru I haven't actually used hakyll deployment command at all personally, so I didn't think about it. I'll have to think about how to integrate that into hakyll-flake-gen.