Cask file organization

[jhenahan]

I may open a similar issue in Cask's tracker if it's more appropriate there, but I had a question/feature request for the way Pallet writes to the Caskfile. I like to put related packages in groups delimited by comments, but Pallet strips all of these when writing the Caskfile.

Would there be a way to respect this sort of system? Alternatively, I could define functions to serve the same purpose and call them at the end of the file (since it's just elisp), but I don't know if Pallet would respect this method of grouping either. Any thoughts?

[rdallasgray]

At present Pallet just rewrites the file on each change, but I see the value of your use case; we could try to do that a bit more intelligently. Could you post an example of how you lay out your Cask file?

[dudebout]

I had the same problem. My file was not very complicated, along those lines:

(source melpa)

(depends-on magit)
(depends-on palet)

;; some comments

I did not care for the full rewrite, which added the url for melpa and removed the comments.

In the emacs tradition, we could maybe define a custom zone where pallet can go wild and keep the rest untouched. Therefore, I get the benefits of pallet, and I can clean up and organize as I wish.

[jhenahan]

As a minimal example, say I have

(source melpa)

;; Evil-mode dependencies
(depends-on "evil")
(depends-on "evil-indent-textobject")
(depends-on "evil-leader")
(depends-on "evil-numbers")
(depends-on "evil-paredit")

;; LaTeX dependencies
(depends-on "auctex")
(depends-on "auctex-latexmk")

;; Language modes
(depends-on "haskell-mode")
(depends-on "erlang-mode")

The alternative strategy would be something like

(defun evil-deps ()
  (
   (depends-on "evil")
   (depends-on "evil-indent-textobject")
   (depends-on "evil-leader")
   (depends-on "evil-numbers")
   (depends-on "evil-paredit")
   )
  )

I sort of like this idea because it opens Pallet up to community-vetted packs ("crates"?) of related functionality. That may be outside the scope of Pallet, but it's an idea.

[Trevoke]

@prooftechnique I like your second strategy better, I think.

[thelastnode]

👍

[ghost]

It would be much simpler if Pallet just appended new dependencies at the end of Cask instead of rewriting the file. Newline at EOF would be nice as well. The current system produces unnecessary churn when your Cask file is under version control.

[rejeep]

Remember that the Cask-file is not an Emacs Lisp file. It is a configuration file, written in Lisp syntax. So we cannot add things such as functions in there.

[DarwinAwardWinner]

I think the best possible solution here is to have a "pallet packing zone" delimited by special comments as suggested by @dudebout. Any time pallet needs to edit something inside the packing zone, it is free to completely rearrange the zone if it wants to (i.e. keep things sorted alphabetically to minimize diffs). But outside the zone, it would just delete the expressions that it needed to and not modify anything else (this would happen if you were uninstalling a package that was listed outside the packing zone). Or there could be an option to never touch anything outside the packing zone.

Unfortunately, looking at the code, something like this would probably require rewriting a lot of Pallet. Pallet loads the Cask file as a cask bundle object, which is just a data structure for dependencies and such, and is not intended to preserve formatting or comments. Basically, to make this happen, you would have to write your own parser for Cask files that preserves all the formatting, and supports in-place editing of elements. It's not impossible to do, but it might not be worth the effort.

As an alternative, might I suggest letting Pallet handle your Cask file and instead organizing your packages using use-package statements with :ensure t in your emacs config? This would cause some redundancy because those packages would also be listed in the Cask file, but other than that I think it's a fine solution. It's what I do, more or less: https://github.com/DarwinAwardWinner/dotemacs/blob/master/config.org#package-configuration