Sitelet https://web.archive.org/web/20211207191441/https://github.com/github/gitignore/pull/3911
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Python] Add poetry.lock #3911

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[Python] Add poetry.lock #3911

wants to merge 1 commit into from

Conversation

@JP-Ellis
Copy link

@JP-Ellis JP-Ellis commented Dec 6, 2021

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.

This is taken from https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control

Reasons for making this change:

This is very similar reasoning to the existing Pipenv entry and Poetry is quite popular too (17.4k stars on Github). As the benefits/cons of including the lock file can vary for each project, the default is left commented out (just as the Pipenv entry).

Links to documentation supporting these rule changes:

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.

This is taken from https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
@bdougie bdougie added the python label Dec 7, 2021
@bdougie
Copy link
Collaborator

@bdougie bdougie commented Dec 7, 2021

I understand the use of the lockfile, but I am curious if you explain the reason for the poetry toml file and if this is related? #3853

Loading

@JP-Ellis
Copy link
Author

@JP-Ellis JP-Ellis commented Dec 7, 2021

So Poetry is a general tool (like npm, yarn, cargo, etc.) and relies on a couple of files:

  • pyproject.toml specifies the project's dependencies (among other project-specific things)
  • poetry.toml specifies general configuration options (and is not typically stored in the project, but instead belong in the user's config directory such as $XDG_CONFIG_HOME
  • poetry.lock which contains the specific versions of dependencies installed by Poetry in order to be able to reproduce an installation exactly (specifically, it contains exact versions and hashes which is in contrast to pyproject.toml which will contain dependency ranges).

Now to address the question on whether poetry.toml should be included or not into .gitignore, I am leaning towards a 'yes' on this. Of the available settings, all of them are clearly user specific instead of project specific with the exception of repositories.<name> which allows for alternative repositories to be specified (e.g. private ones). Having said that, there is an equivalent option with pyproject.toml and that file is definitely project specific thus I do not see why one would prefer poetry.toml over pyproject.toml for this setting and arguably, one should discourage using poetry.toml for this as pyproject.toml is intended to be agnostic of which tool is being used.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants