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

powerdns-admin: fix build #161896

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions pkgs/applications/networking/powerdns-admin/default.nix
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,11 @@ let
version = "1.16.0";
src = oldAttrs.src.override {
inherit version;
extension = "zip";
sha256 = "36c5e8e38d4369a08b6780b7f27d790a292b2b08eea01607865bf0936c558e01";
};
# Needs networking for some tests
doCheck = false;
});
};
};
Expand Down
30 changes: 27 additions & 3 deletions pkgs/development/python-modules/bravado-core/default.nix
Original file line number Diff line number Diff line change
@@ -1,8 +1,32 @@
{ lib, buildPythonPackage, fetchFromGitHub, python-dateutil, jsonref, jsonschema,
{ lib, buildPythonPackage, fetchFromGitHub, fetchPypi, python-dateutil, jsonref, jsonschema,
pyyaml, simplejson, six, pytz, msgpack, swagger-spec-validator, rfc3987,
strict-rfc3339, webcolors, mypy-extensions, jsonpointer, idna, pytest, mock,
pytest-benchmark, isPy27, enum34 }:

let
jsonschema320 = jsonschema.overridePythonAttrs (oldAttrs: rec {
version = "3.2.0";

src = fetchPypi {
inherit (oldAttrs) pname;
Comment on lines +6 to +11
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pinning within python-modules is highly discouraged. This will potentially introduce incompatible versions in a user's environment as either the new pinned version or the original version will be imported at runtime, breaking one of the packages.

The preference to handling this is to relax version bounds in the "install_requires" field. (could be in setup.py, pyproject.toml, requirements or others). In most cases, packages are still compatible with small API changes which may warrant a major version bump. We use test suites to verify that the package still works correctly.

If the package is still incompatible with the latest major version, then the most proper way to handle this is make an issue with the upstream package to adopt the latest major version. Or if upstream is not very responsive, you are free patch the source to make it compatible.

In very few circumstances, two versions of the same package are allowed to exist if the packages are extremely difficult to package. Some examples of this are tensorflow, which has huge ecosystems built around it and is hard to package. Another is django, which has 2 actively developed versions, and large ecosystems built around each.

One exception to this is applications, due to the way buildPythonApplication and toPythonApplication functions work, the related derivations will not bleed dependencies between packages. If the package doesn't need to be imported by other python modules, then this package would be a good candidate to convert into application. You can look at https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/admin/awscli/default.nix as an example of using an overlay within a python application.

Another valid exception is pinning within the same interpreter version. If a package no longer supports older-but-still-relevant interpreter versions, then you're free to pin a package for an interpreter. This was very common with python2, but less common amongst python3 interpreters. (e.g. if (pythonOlder "3.8" then <older pkg> else <latest package> ;)

Info on buildPythonApplication can be found here.
Info on toPythonApplication can be found here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like bravado-core does not work with jsonschema 4, there’s an upstream PR to pin it to <4 because of bugs: Yelp/bravado-core#385
As bravado-core is a library, I also don’t know a way to override it for all dependencies once, therefore the override of swagger-spec-validator to not end up with two different versions of jsonschema (which does not compile).

inherit version;
hash = "sha256-yKhbKNN3zHc35G4tnytPRO48Dh3qxr9G3e/HGH0weXo=";
};

SETUPTOOLS_SCM_PRETEND_VERSION = version;

doCheck = false;
});

swagger-spec-validator' = swagger-spec-validator.overridePythonAttrs (oldAttrs: rec {
propagatedBuildInputs = [
pyyaml
jsonschema320
six
];
});
in

buildPythonPackage rec {
pname = "bravado-core";
version = "5.17.0";
Expand All @@ -26,13 +50,13 @@ buildPythonPackage rec {
propagatedBuildInputs = [
python-dateutil
jsonref
jsonschema
jsonschema320
pyyaml
simplejson
six
pytz
msgpack
swagger-spec-validator
swagger-spec-validator'

# the following 3 packages are included when jsonschema (3.2) is installed
# as jsonschema[format], which reflects what happens in setup.py
Expand Down