JasonGross / guarantees-based-mechanistic-interpretability

guarantees-based-mechanistic-interpretability/.gitignore

Lines 97 to 102 in d87b9c7

    
           # poetry 
        
           #   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control. 
        
           #   This is especially recommended for binary packages to ensure reproducibility, and is more 
        
           #   commonly ignored for libraries. 
        
           #   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control 
        
           #poetry.lock

Maybe we should remove

guarantees-based-mechanistic-interpretability/.gitignore

Line 161 in d87b9c7

poetry.lock

?

Questions:

Will this break cross-platform development?
Do we want to have CI test on multiple versions of python, and will having a lock file interfere with this?
Do we want to have CI test multiple versions of poetry, and will having a lock file interfere with this?

Currently CI tests

guarantees-based-mechanistic-interpretability/.github/workflows/ci.yml

Lines 18 to 28 in d87b9c7

    
           python-version: ["3.9", "3.10", "3.11"] 
        
           poetry-version: ["1.2.2", "1.7.1"] 
        
           os: [ubuntu-latest] 
        
           include: 
        
           - python-version: "3.11" 
        
             poetry-version: "1.7.1" 
        
             os: macos-latest 
        
           - python-version: "3.11" 
        
             poetry-version: "1.7.1" 
        
             os: windows-latest 
        
             poetry-install-extra-args: "--compile"

If we change this, presumably we'll want to add hashFiles('poetry.lock') to

guarantees-based-mechanistic-interpretability/.github/workflows/ci.yml

Line 58 in d87b9c7

    
           key: venv-${{ hashFiles('pyproject.toml') }}-${{ matrix.python-version }}-${{ matrix.poetry-version }}-${{ matrix.os }}

and maybe remove some subset of the existing key.

see https://python-poetry.org/docs/basic-usage/ -- seems to suggest committing the lock makes sense?

Okay, let's try it. I'm concerned that the lockfile is going to pin some pytorch cuda packages specific to some particular GPU and the lockfile for the node / MacOS / WSL / Linux are all going to conflict. Maybe it'll magically work, but we should keep an eye out.

	# poetry
	# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
	# This is especially recommended for binary packages to ensure reproducibility, and is more
	# commonly ignored for libraries.
	# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
	#poetry.lock

	python-version: ["3.9", "3.10", "3.11"]
	poetry-version: ["1.2.2", "1.7.1"]
	os: [ubuntu-latest]
	include:
	- python-version: "3.11"
	poetry-version: "1.7.1"
	os: macos-latest
	- python-version: "3.11"
	poetry-version: "1.7.1"
	os: windows-latest
	poetry-install-extra-args: "--compile"

Should we commit poetry.lock?