pipenv-unlock

Entrypoint for dependency lock unlock and fix

drain_swamp.cli_dependencies.entrypoint_name: str = "pipenv-unlock"

Command line entrypoint file name

drain_swamp.cli_dependencies.help_path: str

cli option --path doc string

drain_swamp.cli_dependencies.help_venv_path: str

cli option --venv-relpath doc string

drain_swamp.cli_dependencies.help_timeout: str

cli option --timeout doc string

drain_swamp.cli_dependencies.help_is_dry_run: str

cli option --dry-run doc string

drain_swamp.cli_dependencies.help_show_unresolvables: str

cli option --show-unresolvables doc string

drain_swamp.cli_dependencies.help_show_fixed: str

cli option --show-fixed doc string

drain_swamp.cli_dependencies.help_show_resolvable_shared: str

cli option --show-resolvable-shared doc string

drain_swamp.cli_dependencies.EPILOG_LOCK: str

Exit codes explanation for command, lock

drain_swamp.cli_dependencies.EPILOG_UNLOCK: str

Exit codes explanation for command, unlock

drain_swamp.cli_dependencies.EPILOG_REQUIREMENTS_FIX: str

Exit codes explanation for command, fix

drain_swamp.cli_dependencies.main()

pipenv-unlock --help, prints help

pipenv-unlock COMMAND --help, prints help for a command

Table 12 Commands

command

creates

desc

lock

.lock

Create lock dependency file

unlock

.unlock

Create unlock dependency file

fix

In requirements, fixes/reports dependency conflicts
drain_swamp.cli_dependencies.dependencies_lock(*args: Any, **kwargs: Any) → Any

Lock dependencies creates (*.lock) files

Disadvantages of locking dependencies

  1. FOSS is as-is, largely unpaid work, often lacks necessary skillset, often doesn’t care to do tedious tasks, is pressed for time, and live happens. These are the people supposed to be making packages for production use?! Having such expectations is ridiculous and conflicts with the human condition

  2. package quickly becomes unusable when, not if, the author is no longer maintaining the package

  3. Non-experts might not be using pipenv, only pip. Almost guaranteeing dependency hell. pip won’t have what it needs to resolve dependency version conflicts

  4. pipenv says don’t automate updating dependency lock files thru CI/CD

  5. Multiple calls to pip-compile always causes avoidable mistakes; choosing non-sync’ed dependency versions.

Advantage

  1. Job security. Knowledgable eyeballs must regularly update dependency version locks

  2. pipenv discourages attackers setting up alternative repository hosts pypi.org and swapping out an obscure package with their own.

  3. The stars align in the cosmos, miraculously, all package authors regularly update their packages dependencys’ locks. Get that warm feeling inside knowing we are alive, loved, and appreciated. We shout, it's a miracle! and be right!

Usage

pipenv-unlock lock

or

python src/drain_swamp/cli_dependencies.py lock

Parameters:

  • path (pathlib.Path) – The root directory [default: pyproject.toml directory]

  • venv_relpath (pathlib.Path) – Filter by venv relative path

drain_swamp.cli_dependencies.dependencies_unlock(*args: Any, **kwargs: Any) → Any

Unlock dependencies creates (*.unlock) files

Package dependencies are only locked if the package is an app. A .in resolves -r and -c, which can be understood by pip

Usage

pipenv-unlock unlock

or

python src/drain_swamp/cli_dependencies.py unlock

Parameters:

  • path (pathlib.Path) – The root directory [default: pyproject.toml directory]

  • venv_relpath (pathlib.Path) – Filter by venv relative path

drain_swamp.cli_dependencies.requirements_fix(*args: Any, **kwargs: Any) → Any

Goes thru .lock and .unlock files, fixing resolvable dependency resolution conflicts. Reporting what needs manual care.

For unresolvable or sensitive resolvable issues, manually apply fixes to applicable [.shared].in files. Then rerun the cycle

pipenv-unlock lock
pipenv-unlock unlock
pipenv-unlock fix

Reporting:

  • Resolved issues

    Long list of resolved dependency issues. Every entry represents tedious error prone work that no longer has to be done manually

    Python users are tormented by dependency resolution conflicts. With little or no possible relief besides applying manual fixes.

  • Resolvable but file is shared across more than one venv.

    These files end in .shared.{.unlock, .lock} suffixes. Fix algo deals in one venv, not multiple venv. Instead of fixing, issue is reported.

  • unresolvable dependency conflict

    Details the affected files and conflict details. Something has to give. And a human needs to figure out what.

    Find the offending dependency package and look at pyproject.toml. Paying attention to dependency version restrictions.

    use a different package release version or raise the issue with the upstream package maintainers

    Popular packages wield power for their mistakes to affect the most people. Look out for abandonware or packages wrapping C code.

Assumes familiarity with and usage of:

  • pyproject.toml [[ tool.venvs ]] sections

  • .in, .unlock, and .lock files. Fix not applied to (.shared).in files.

Parameters:

  • path (pathlib.Path) – The root directory [default: pyproject.toml directory]

  • venv_relpath (pathlib.Path) – Filter by venv relative path

  • is_dry_run (Any | None) – Default False. Should be a bool. Do not make changes. Merely report what would have been changed

  • show_unresolvables (bool) – Default True. Report unresolvable dependency conflicts

  • show_fixed (bool) – Default True. Report fixed issues

  • show_resolvable_shared (bool) – Default True. Report resolvable issues affecting .shared.{.unlock, .lock} files.