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: unsupported platforms check and buildPythonApplication support #128

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ryneeverett
Copy link
Contributor

For context, I first typed the substance of this out over a year ago when I was looking for automated ways to avoid some of the review comments I received from Sandro in NixOS/nixpkgs#110620. As I recall, the reason I got stuck and forgot about it is that overlays have to be added to the git index in order for their checks to be discovered and applied which seems like a nixpkgs-hammering limitation that ought to be removed or documented.

Copy link
Owner

@jtojnar jtojnar left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution. cc'ing @SuperSandro2000 as this is based on his suggestion.

overlays have to be added to the git index in order for their checks to be discovered and applied which seems like a nixpkgs-hammering limitation that ought to be removed or documented.

This is Nix flakes limitation so docs are probably the only solution.

explanations/python-unsupported-platforms.md Outdated Show resolved Hide resolved

checkDerivation = drvArgs: drv:
let
python = lib.lists.last (builtins.filter (p: p ? pythonVersion) drv.propagatedBuildInputs);
Copy link
Owner

Choose a reason for hiding this comment

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

I am not very confident about this. Maybe add a comment pointing to the source code so that we can easily update this when it breaks: https://github.com/NixOS/nixpkgs/blob/dbe1337750f324137ca2ba78f20a3be00e16481a/pkgs/development/interpreters/python/mk-python-derivation.nix#L155

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I had not seen the comments added by NixOS/nixpkgs#179318 which does seem to draw into question the long-term inclusion of python as an input.

overlays/python-unsupported-platforms.nix Show resolved Hide resolved
sources = [
"buildPythonPackage"
sources = if drv ? pythonModule
then [ "buildPythonPackage"
Copy link
Owner

Choose a reason for hiding this comment

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

What is the goal of including this in the error message?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not convinced the inclusion provides any value but I followed the existing pattern. Here's an example error message as it currently stands:

$ nix run ../nixpkgs-hammering hindsight
warning: Git tree '/home/user/nixpkgs-hammering' is dirty
error: build log of '/nix/store/z36zmlak3h7x5kxcg4mr3fm7pj6w0zbf-hindsight-2021.01.16' is not available
error: build log of '/nix/store/z36zmlak3h7x5kxcg4mr3fm7pj6w0zbf-hindsight-2021.01.16' is not available
When evaluating attribute ‘hindsight’:
warning: python-inconsistent-interpreters
Between buildPythonApplication and propagatedBuildInputs, this derivation seems
to be simultaneously trying to use packages from multiple different Python package sets.
Mixing package sets like this is not supported.

Detected Python packages:

- python3-3.8.7
- python-2.7.18

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/python-inconsistent-interpreters.md

Shall I remove "buildPythonPackage" and "buildPythonApplication" from these messages?

overlays/python-inconsistent-interpreters.nix Outdated Show resolved Hide resolved
@@ -0,0 +1,26 @@
final: prev:
Copy link
Owner

Choose a reason for hiding this comment

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

In the future, we will probably want the same rule for other languages like Go and Rust. I wonder if we should name this rule e.g. language-builder-unsupported-platforms to allow easily extending it in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe but it seems like it could get messy trying to get the default platform of every builder in one overlay. Perhaps it would make more sense to abstract the shared logic into a checkDefaultPlatformsForBuilder method in lib?

This effects python-inconsistent-interpreters because we can no longer
assume there to be a drv.pythonModule attribute.
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