Add *.pyc to .gitignore

[lencioni]

When using this repo as a git submodule, it can be annoying to have the
.pyc files dirtying up the work tree. Adding them to the .gitignore file
prevents this.

Fixes #227.

[amoffat]

Hi Joe, I'd prefer to leave .gitignore out of the repo. You can create a global gitignore for your system, or a individual .gitignore and add .gitignore to the file

[lencioni]

Thanks for the fast response!

I am aware that I can create a global gitignore and solve this problem for myself, but I was hoping to solve it for everyone else at the same time. Why do you want to leave .gitignore out of the repo?

[amoffat]

Different people have different exclusions. People on OSX might have .DS_Store, while people using vim might add .swp and .swo, etc. Makes more sense to me for people to manage their own common exclusions globally for their system, or locally for their repo, and have as few metafiles cruft in each repo as possible. My .gitignore for sh has a number of helper scripts that I exclude, but nobody else would need to know about.

[lencioni]

I'm not that familiar with Python, so I could be way off here, but aren't .pyc files created when .py files are executed? I can understand not adding environment-specific files like .DS_Store and .swp to a .gitignore file, but .pyc files seem specific to this project. Again, I don't really know that much about Python, so it is likely that I am completely misunderstanding how these files come to be and their relationship with the project and environment.

[amoffat]

You're right that .pyc files are generated by Python in a typical environment. Suppose I check in .gitignore, what would I do with the excludes I've personally added? Suppose I leave those uncommitted, now my .gitignore file claims to be modified every time I run git status. Suppose I add ".gitignore" to the .gitignore file and commit that, then re-add my exclusions. Well this won't work because .gitignore is tracked, so any custom changes will perpetually show .gitignore as being changed. Even if that did work, I could never do a git reset --hard or I'd blow away my custom additions, because .gitignore is tracked.

I've been down this path, I believe it's best to not track .gitignore :)

[arthurdarcet]

I my opinion, the .pyc files are repo-related and should therefor be ignored at the repository level ; while the .DS_Store, .swp, … ones are OS-related and should be ignored in a global gitignore.

In the unlikely case where you need to ignore files for this specific project but those ignores shouldn't be committed, it is always possible to setup another gitignore file in the .git/config.

[amoffat]

@arthurdarcet I agree that the .pycs are repo-related, but I'd argue that .gitignore is versioning-system related. It's a file that doesn't belong to the code of the project, because if I were to switch to, say, Mercurial, it would be obsolete. .gitignore is a convenience tool of the versioning system, nothing more. The argument is whether or not it's so convenient to everyone that belongs in the project's source code.

However, doing a little research on local gitignores led me to this, which lets me have exclusions that I don't have to commit by putting them in .git/info/exclude. In light of that, including .gitignore is no longer inconvenient to me, so I'm gonna merge this

[lencioni]

Great! Thanks for reconsidering! 👍