Obsolete Hugo-rendered files

feature
1

Continuing issue 2389:

A safer solution would be to add a sub-command to hugo list. An output sub-command would expand the scope of list a bit, but I think list is the right place to put this functionality. For example:

> hugo list output   List all files Hugo shall write in outputDir

@moorereason @snapo, this seems generally useful, and safe. :slight_smile:

However, listing “what Hugo shall write” seems IMO not to address the issue of obsolete Hugo files in the ./public/ tree directly. (At least, I don’t see how.)

I say this, because I suppose you’re referring to files which Hugo currently calculates it will write to outputDir. Presumably, Hugo would base this on the present state of its trees ./content/, layouts/, and static/, etc.

Possibly you mean that Hugo would keep a log of its past writes (i.e., the file paths).

> hugo list output --orphans   List all files in outputDir not part of Hugo

Listing “files…not part of Hugo” seems IMO not to address it directly, either. Of course, this list would include any other files and directories a Hugo user might have placed in ./public. That might be useful—or, it might be distracting.

How can Hugo know what particular files were “part of Hugo” in the past? For Hugo’s obsolete files, this seems the relevant question.

To address this small “problem” of obsolete files, some sub-command of hugo list IMO could be implemented to print what Hugo has rendered (created or copied) in the past. This then would include the obsolete files rendered by Hugo.

Or, perhaps some sub-command of hugo list IMO could be implemented to print only those obsolete files.

Then, in order to remove Hugo’s obsolete files, a user himself would type (if implemented):

rm `hugo list --obsolete`

Or, to remove Hugo’s rendered files—both obsolete and currently valid—a user himself would type (if implemented):

rm `hugo list --historical`

tl;dr

While they focus on helping power users like themselves, I suppose developers sometimes have a tendency to ignore some of the comfort issues felt by new and “unsophisticated” users.

In that light, implementing either of the commands:

  1. hugo list output --historical; or
  2. hugo list output --obsolete

IMO would help Hugo, by increasing its feeling of safety for some new or “unsophisticated” Hugo users (those who seem less comfortable with the command line), who have reported (in effect) a reluctance to type rm -rf public/ themselves.

Naturally, I myself have no problem typing rm -rf public/! :slight_smile:

2

Mark,
You have a knack for over-complicating everything. :trophy:

You mention “obsolete Hugo files.” The hugo list output --orphans command would solve that problem. As a rule, I never manually put any files directly into the output directory. I put them in static/, and let Hugo copy them. That’s why I call them “orphans.” If a user is manually copying files into the output directory, they get the added challenge of managing the mess.

You also mention historical record-keeping. I’m going to go out on a limb and say that Hugo will never track that. Hugo only cares about a single point in time. If you want to create historical manifests, you could use hugo list output and build your own tracking system.

1 Like
3

This is an excellent argument—you’ve convinced me. :slightly_smiling:

hugo list output --orphans is the right solution.