Skip to main content

sync Pipfile/Pipfile.lock to

Project description


travis-badge PyPI pyversions codecov PyPI version Very popular Code style: black

A beautiful python package development tool: sync dependencies in Pipfile or Pipfile.lock to

Never need again to change dependencies manually in, and enjoy the same dependency locking or semantic versioning.

Or just check whether and Pipfile are consistent and sync dependency when necessary.


Create a command line entry point pipenv-setup, and add pipenv-setup as a dev package in Pipfile:

pipenv install --dev pipenv-setup


Beautiful pipenv flavored help

$ pipenv-setup


Sync to

  • supports assorted package configuration. You can have a pipfile as ugly as you want:

    requests = { extras = ['socks'] }
    records = '>0.5.0'
    django = { git = '', ref = '1.11.4', editable = true }
    "e682b37" = {file = ""}
    "e1839a8" = {path = ".", editable = true}
    pywinusb = { version = "*", os_name = "=='nt'", index="pypi"}

    pipenv-setup will still figure things out:

    $ pipenv-setup sync
    package e1839a8 is local, omitted in successfully updated
    23 packages from Pipfile.lock synced to

    And things will be where they should be:

            "pywinusb==0.4.2; os_name == 'nt'",
  • provide --dev flag to sync development packages with extras_require:

    $ pipenv-setup sync --dev successfully updated
    1 default packages from Pipfile.lock synced to
    1 dev packages from Pipfile.lock synced to
    # produced
        extras_require={"dev": ["pytest==1.1.3",]},
  • produce beautiful Blackened file

  • Template generation with filled dependencies in the absence of a setup file.

    $ pipenv-setup sync not found under current directory
    Creating boilerplate was successfully generated
    23 packages synced from Pipfile.lock to
    Please edit the required fields in the generated file

    Note: by default, pipenv-setup syncs lockfile instead of pipfile

Sync Pipfile vs. Pipfile.lock

Provide --pipfile flag to sync Pipfile instead of Pipfile.lock.

pipenv-setup will perform a liquid sync using semantic versioning taken from Pipfile (instead of using frozen pinned versions from Pipfile.lock):

$ pipenv-setup sync --pipfile was successfully updated
23 packages synced from Pipfile to

Checks Only

run $ pipenv-setup check

  • checks four items

    • local package in default pipfile packages
    • Package version requirements in install_requires in that potentially violates Pipfile
    • Package version requirements in dependency_links in that differs from Pipfile
    • Default package in pipfile missing in install_requires or dependency_links in
  • exits with non-zero code when conflict found (can be used in travis-ci)

  • here is a somewhat extreme example:

    $ pipenv-setup check
    package 'numpy' has version string: >=1.2 in, which potentially violates >=1.5 in pipfile
    package 'pywinusb' has version string: ==0.4.2 in, which is disjoint from ~=0.3.0 in pipfile
    package 'records' has version string: >=0.4.2,<0.5 in, which is disjoint from >0.5.0 in pipfile
    package 'django' has branch/version 1.11.5 in dependency_links, which is different than 1.11.4 listed in pipfile
    package 'requests' in pipfile but not in install_requires
    package 'e682b37' has a url in pipfile but not in dependency_links
    (exits with 1)
  • provide --ignore-local flag to allow local packages in pipfile

    $ pipenv-setup check
    local package found in default dependency: e1839a8.
    Do you mean to make it dev dependency
    (exits with 1)
    $ pipenv-setup check --ignore-local
    No version conflict or missing packages/dependencies found in!
    (exits with 0)
  • provide --strict flag to only pass identical version requirements

    By default pipenv-setup check passes when the version specifies is "compatible" with Pipfile, i.e. is a subset of it. For example, a Pipfile specifying django~=1.1 with requiring django==1.2 is such a case.

    Provide --strict to allow only identical requirements; i.e. for Pipfile's django~=1.1, must require django>=1.1,<2.0

    Example output:

    $ pipenv-setup check --strict
    package 'pywinusb' has version string: ==0.4.2 in, which specifies a subset of * in pipfile
    package 'django' has version string: >=0.5 in, which is disjoint from ~=0.3.0 in pipfile
    package 'records' has version string: ==0.5.2 in, which specifies a subset of >0.5.0 in pipfile
    package 'requests' has version string: ==2.18.4 in, which specifies a subset of * in pipfile
    (exits with 1)
  • provide --lockfile flag to check against Pipfile.lock instead of Pipfile

    By default, pipenv-setup check compares the dependencies from against the dependencies listed in Pipfile. This works well for most cases, but there are some exceptions that break this strategy, including (but not necessarily limited to):

    • VCS dependencies with a mutable ref (e.g. - git branch name instead of a tag or commit sha)
      • Because these resolve to an immutable pointer (e.g. - commit sha) in, the dependency will no longer match between and Pipfile. However, Pipfile.lock will contain the same resolved pointer as


If you'd like to contribute to pipenv-setup, see Contribution Guide

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for pipenv-setup, version 3.1.1
Filename, size File type Python version Upload date Hashes
Filename, size pipenv_setup-3.1.1-py3-none-any.whl (24.8 kB) File type Wheel Python version py3 Upload date Hashes View
Filename, size pipenv-setup-3.1.1.tar.gz (25.6 kB) File type Source Python version None Upload date Hashes View

Supported by

AWS AWS Cloud computing Datadog Datadog Monitoring Facebook / Instagram Facebook / Instagram PSF Sponsor Fastly Fastly CDN Google Google Object Storage and Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Salesforce Salesforce PSF Sponsor Sentry Sentry Error logging StatusPage StatusPage Status page