Add an ignored files config to prevent freezing from overwriting/removing files

[croach]

I am using Frozen-Flask to create my blog which I publish through Github Pages. The problem is that freezing removes all of the files in the .git directory of the blog's github repo which kills the repository. I could build to a different destination and then copy over all of the files to my github repo, but that is a tedious and error prone process. Instead, it would be nice to have a config setting that would allow you to specify files and directories to ignore during the freezing process (something akin to the .gitignore file).

The changes I've made in this pull request introduce a new config setting FREEZER_IGNORED_FILES to fix this issue. The ignored files setting takes a list of file and directory names (relative to the destination directory) and expands those into a list of ignored file paths.

So, for example, if you wanted to ignore all files within the .git directory of a Git repo and a CNAME file within the top level of the destination directory, you could add the following to your script:

FREEZER_IGNORED_FILES = ['.git', 'CNAME']

[SimonSapin]

Related to, maybe duplicate of #23.

[croach]

Yep, this looks like a duplicate to me as well. The two solutions are slightly different though. Jim uses fnmatch to see if strings in the FREEZER_IGNORED_FILES config setting match up to any files in the list of extra files. My code, on the other hand, uses the walk_directory method in a manner similar to way the previous_files set is constructed to create a set of all the file paths that match the FREEZER_IGNORED_FILES setting and then removes them from the previous_files set.

The difference is very subtle but has some implications to the user. I feel that Jim's solution puts more of a cognitive burden on the part of the user since they are responsible for either constructing full file paths or properly adding wildcards where needed. You can see this in the example Jim put in his docs for ignoring the hidden .git folder in a Git repo:

FREEZER_IGNORED_FILES = ['*/'+FREEZER_DESTINATION+'/*.git*','*/.git/*']

My solution makes the assumption that anything in the FREEZER_IGNORED_FILES setting is relative to the destination directory and tries to use the same code that is used for creating the previous_files set to keep the behavior between the two similar. The same example with my code would look like the following:

FREEZER_IGNORED_FILES = ['.git']

Both solutions work and solve the same problem and both have their pros and cons, so it just depends on where you stand as to which solution better fits the Frozen-Flask code base.

[shuhaowu]

Can we please get this merged? If not I'm going to have to fork this out and embed it into a script that I'm writing.

[SimonSapin]

Thanks for contributing, and sorry I let this get delayed. I just pushed something based on both this and #23. Let me know if this works for you, I’ll make a release.

[SimonSapin]

Released in 0.10. Please open new issues if the feature or anything is buggy.

[shuhaowu]

+1. Awesome.

[croach]

@SimonSapin the changes you committed look good to me. Funny enough, you went the route I originally started out with (i.e., adding an ignore parameter to walk_directory). I decided against it mainly because I didn't know the codebase that well and so I wanted to introduce as few changes as possible, so as to not introduce any side effects. So, actually I like this solution better than what I submitted. Thanks a bunch for adding it.

[shuhaowu]

As probably a side discussion (idk if there is one for this library)... it seems like I still might want to fork this out and embed it into funnel... I see I need to retain the copyright notice.. for clarity can I stick that notice into the source file that I'm going to fork from this?

[SimonSapin]

@shuhaowu the intent of using a BSD license is certainly to allow you to use or fork Frozen-Flask in any way you want. Moving the copyright notice to file headers is fine.

That said, I would prefer if you submit improvements for inclusion rather than maintain your own fork. Is there still something missing that you’d need?

[shuhaowu]

No the library is good as is. I have a couple of very specific changes that will be no use to the upstream library in mind that I want to try out. Obviously if I did anything useful, I'll send off a PR to upstream (here).