-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
old files keep lying around in staging-dir and output-dir #72
Comments
What do you mean by the "git backend"? More details on how to reproduce would be appreciated. |
.coleslawrc:
After generating old generated files keep showing up in I myself fixed this like this: http://lukasepple.de/posts/coleslaw-helpers.html |
Just now an idea came to my mind. We could write a cli interface (using cl-launch) to solve that elegantely:
(Just like Hakyll) |
I think it would be nice if we agree on one set of cli command that gets implemented. |
I would love to see such a pull request, or at least more details on what a solution like that looks like. I'm happy with your proposed set of commands. It might be nice for people who aren't doing "git-style" deploys to have a |
Good idea! Maybe we can also have a (ql:quickload :hunchentoot)
(ql:quickload :coleslaw)
(defun build-blog ()
(coleslaw:main #p"/home/qwfwq/blog/post/"))
(defun serve ()
(hunchentoot:start (make-instance 'hunchentoot:easy-acceptor
:port 4242 :document-root #p"/home/qwfwq/blog/www/"))) Then I can use (I am a common lisp newbie now,maybe I can do something some day.) |
@erlFelaP Good idea, thanks! I'd forgotten about shelly. That might be perfect for this. |
I currently use cl-launch to build, as the script is pretty much the same as the githook. The pros of cl-launch is that is looks like any other CLI tool from the perspective of the user, the cons are that they require an additional installation from the perspective of the user and that error messages are make clojure's stack traces look concise. a problem when not when debugging (as one can just use the REPL) but certainly for when an user wants to submit an error report. Maybe shelly fares better in this regard? #!/usr/bin/cl -Q -sp coleslaw --entry entry
;;;;
;; This script assumes it is executed from the repository's top level directory
;; to determine correctly the blog-dir variable.
;;;;
(defun entry (argv)
(declare (ignorable argv))
(let
((old-rev (inferior-shell:run/s
"git log --oneline -1 | awk -e '{print $1}'"))
(blog-dir (uiop/os:getcwd)))
(main blog-dir old-rev))) If recently found about eazy-project which supports skeletons for scaffolding (akin to leiningen). Although it doesn't appear to be easily extendable. Should we open a branch to start working the command set proposed by Lucas + the serve commands? |
I would love that. I think shelly and cl-launch are both good options. I'd be happy to bundle code for both. Let's cut a branch called |
I would like to help doing that. As a downside of shelly you would not have a |
That's true. We could always have a shell alias |
Sounds good! |
I was able to create a simple coleslaw binary like this: buildapp \
--output coleslaw \
--asdf-path "." \
--load-system coleslaw \
--asdf-tree "~/quicklisp/dists/quicklisp/software/" \
--eval '(defun main (argv)
(declare (ignore argv))
(coleslaw:main "."))' Biggest Problem: Size is 83MB. Using
|
The buildapp binary is currently weirdly broken. A more sophisticated build script woud look like this: #!/bin/sh
fatal() {
echo "$1"
exit 1
}
test -f ~/quicklisp/setup.lisp || fatal "You need quicklisp to use coleslaw"
sbcl --no-userinit --no-sysinit --non-interactive \
--load ~/quicklisp/setup.lisp \
--eval '(dolist (systems (quote ("closure-template" "3bmd" "3bmd-ext-code-blocks" "alexandria" "local-time"
"inferior-shell" "cl-fad" "cl-ppcre" "closer-mop" "cl-unicode")))
(ql:quickload systems))' \
--eval '(ql:write-asdf-manifest-file "quicklisp-manifest.txt")'
buildapp \
--output coleslaw \
--asdf-path "." \
--load-system "coleslaw" \
--manifest-file "quicklisp-manifest.txt" \
--eval '(defun main (argv)
(coleslaw:main "."))' || fatal "buildapp failed!" Running resulting binary fails for me with strange errors maybe someone can find out what they mean:
|
I think cl-launch could be a more reasonable alternative to buildapp |
Yeah, I wouldn't worry with standalone binaries/buildapp just yet. Some users would probably be fine with installing an 80mb executable to run coleslaw. We can look into it later. For now, let's just get a nice CLI interface up with cl-launch or shelly. Trying to get a binary for folks that don't want to install SBCL, Quicklisp, etc would be very cool. I'll open an issue for that. |
I've pushed some preliminary changes to the cli-commands branch. A couple of things:
Anyhow, thoughts/feedback? Happy Holidays |
Awesome work, @PuercoPop! 👍 I skimmed it and it looks good on the whole. I feel like process-parameters could be cleaner for some reason but haven't thought about it too carefully. Will try to test it out and report back in the next few days. :) |
I've pushed some more work to the cli-commands branch, rebasing to current master. I've switched from cl-launch to buildapp. Also using command-line-arguments to parse argv. however because I'm using a 'command' cli interface (a la git) we can't use the auto-generated usage. I've yet to evaluate if Clon handles the usage case better. Following pjb's writting style of using the documentation option of defpackage I've written the help text of the command in the defpackage form, I'm not convinced it is the best idea, maybe just using the docsting would be better? Also I've followed a one-package per-file (which I don't really like tbh because it makes working with the REPL a little bit harder) but could use the traditional one packages. file used in coleslaw. Anyhow below I list the items that need work before a merge, feel free to add what you think is missing and any feedback. Things I want to do before merging
It also addresses #77. |
@PuercoPop: Quite excited to have a look this weekend. Thanks! :) |
@PuercoPop: Great job getting buildapp set up and making solid progress on the cli-commands branch. I definitely prefer the buildapp version to cl-launch. As noted, the config logic is a little messy. That probably just means it could use a rewrite anyway though. :) The one other thing that bugs me is that the current plugin system interacts badly with binary deployment. In an ideal world, I'd love to be able to have a build farm kick out binary releases that users could just download, add configuration, and start blogging. Plugins must be compiled in at build time though. I'll think more on this but I we definitely should not block the initial release because of that. |
One way to handle plugins would be to make a proper asdf definition for each one. And an [1]: The variable would be cl-user for, as eclipse the wm, or a coleslaw.config package. |
when not using the git backend.
The text was updated successfully, but these errors were encountered: