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

Provide environment reproducibility #89

Closed
wants to merge 1 commit into from
Closed

Provide environment reproducibility #89

wants to merge 1 commit into from

Conversation

mataha
Copy link

@mataha mataha commented Jan 4, 2024

Description

This commit introduces environment reproducibility to the project. This is done by compiling a requirements file (via pip-compile) with all dependencies locked to specific versions (like lockfiles used by e.g. Node package managers) to achieve package consistency.

Motivation and Context

Locking down 2nd+ degree dependencies (especially pillow) to prevent random breakages.

How Has This Been Tested?

Yes, using pip-sync.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have read the CONTRIBUTING document.

@deathaxe
Copy link
Member

deathaxe commented Jan 4, 2024

What's the reason for this?

I've never experienced issues with currently rolling releases and don't actually want to start bothering about versions.

This commit introduces environment reproducibility to the project.
This is done by compiling a requirements file (via `pip-compile`)
with all dependencies locked to specific versions (like lockfiles
used by e.g. Node package managers) to achieve package consistency.
@mataha
Copy link
Author

mataha commented Jan 5, 2024

What's the reason for this?

Recommended workflow for managing and generating requirements files; I admit I got cut on installing black once.

I've never experienced issues with currently rolling releases and don't actually want to start bothering about versions.

This is likely a one-time thing. There's no need to be bothered.

@deathaxe deathaxe closed this Apr 7, 2024
@mataha
Copy link
Author

mataha commented May 18, 2024

I still think there's value in pinning dependencies, especially when working with locally installed Python versions that differ from system-wide ones (e.g. I mainly use 3.12, but Sublime packages obviously require 3.8).

That said, it's not a hill I would like to die on - I've given up on trying to manage Python dependencies in a sane way and have since moved to greener pastures.

@mataha mataha deleted the build/reproducible branch May 18, 2024 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants