46

I forked a GitHub project in Python. After running the project for the first time, some .pyc files appeared inside. Should I put them under version control and commit them to my fork?

Erel Segal-Halevi
  • 33,955
  • 36
  • 114
  • 183
  • 11
    NO! ............ – William Pursell Aug 20 '15 at 05:26
  • 3
    No, it is "byte compiled" versions of the same code. See http://stackoverflow.com/questions/3878479/python-pyc-files-main-file-not-compiled – Jordfräs Aug 20 '15 at 05:27
  • Most sources suggest not to, as it can create extra work before committing, and often results in the committing of new source code, but old compiled code. [source 1](http://programmers.stackexchange.com/questions/192113/do-i-check-generated-code-in-to-source-control-or-not), [source 2](http://stackoverflow.com/questions/893913/should-i-store-generated-code-in-source-control) – Addison Aug 20 '15 at 05:29
  • That's somewhat a matter of opinion. However it's customary not to add source control to files that are created during the build process (and consequently is created from the other files in source control), `.pyc` files is among these. Instead you could add `*.pyc` to `.gitignore` and (maybe - this is also a matter of opinion) put `.gitignore` under source control. – skyking Aug 20 '15 at 06:04
  • 2
    @skyking why _wouldn't_ you put `.gitignore` under source control? – ganduG Aug 20 '15 at 06:30
  • @gandu It's to some degree a matter of opinion. *I* would put `.gitignore` under source control, others may have another opinions. – skyking Aug 20 '15 at 06:34
  • @skyking Yeah, I get that. I was just wondering if you knew of any good reasons not to since I couldn't think of any. – ganduG Aug 20 '15 at 06:35
  • 1
    I don't see how this is a matter of opinion; expecting users to individually define an ignore file is unnecessary work and can lead to erroneous commits. If your project generates files or paths that aren't supposed to be part of the repo, you should have a checked-in `.gitignore` file. If there are system-specific files that need to be ignored, those should be specified in [`~/.gitconfig`](http://git-scm.com/docs/gitignore). – dimo414 Aug 20 '15 at 12:44
  • 1
    Use `.gitignore` for patterns that need to be shared by everybody, and `.git/info/exclude` for a private list of patterns. – Flimm Jan 12 '17 at 09:15

4 Answers4

46

You shouldn't. .pyc files contain bytecode, which can be different for different versions and implementation of Python.

Just add *.pyc line in your .gitignore or global gitignore.

Also take a look at the great collection of gitignore files for almost all platforms. You can use this one for your python projects:

# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# C extensions
*.so

# Distribution / packaging
.Python
env/
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*,cover

# Translations
*.mo
*.pot

# Django stuff:
*.log

# Sphinx documentation
docs/_build/

# PyBuilder
target/
svfat
  • 3,273
  • 1
  • 15
  • 34
  • 4
    Personally, I'd much prefer to ignore files as needed than check in a bunch of ignore patterns that aren't actually used. – dimo414 Aug 20 '15 at 12:40
13

These files are compiled versions of the code already in the repo, so that Python can execute the code faster. Since they are a direct computational result of the actual source code there's no benefit to checking them in - they'd just need to be updated every time the source code was updated. Also, there's no guarantee (to my knowledge) that different machines or versions of Python will generate compatible .pyc files, meaning distributing the .pyc files you generated could potentially break other people's environments.

Instead you could fix the .gitignore file to ignore .pyc files and commit that to your fork (or even back to the upstream repo). That way no one will notice or need to worry about these files in the future.

Community
  • 1
  • 1
dimo414
  • 47,227
  • 18
  • 148
  • 244
5

There isn't anything bad about the file, but it's useless junk, it's there only to speed up python application execution, and it's rebuilt every time you make changes, so it will just grow over time, to fix it you might want to add __pycache__ line to your .gitignore file

Aleksandr Tihomirov
  • 71
  • 6
3

No. You must not put pyc under version-control

Common rule is "Never put build-artifacts into source control, because you have sources in source-control and can|have to repeat process"

PYCs are such artifacts for corresponding PY files

dimo414
  • 47,227
  • 18
  • 148
  • 244
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110