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

[wip] wafHook: don’t depend directly on python #69310

Closed
wants to merge 1 commit into from

Conversation

matthewbauer
Copy link
Member

Uses python as fallback when it is not in the environment.

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
Notify maintainers

cc @

@@ -1,9 +1,9 @@
{ lib, stdenv, pkgs, python, makeSetupHook, waf }:
{ lib, stdenv, pkgs, python3, makeSetupHook, waf }:
Copy link
Member

Choose a reason for hiding this comment

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

Should this go to the callPackage?

Copy link
Contributor

Choose a reason for hiding this comment

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

I too tend to agree with this approach - perhaps we should have 2 different wafHooks - one that's called with default python and the other with { python = python3 }.

@FRidh
Copy link
Member

FRidh commented Sep 23, 2019

What is the motivation? What issue does it solve?

@FRidh
Copy link
Member

FRidh commented Sep 23, 2019

motivation #69305 (comment)

@@ -10,6 +10,11 @@ wafConfigurePhase() {
wafConfigureFlags="${prefixKey:---prefix=}$prefix $wafConfigureFlags"
fi

if ! command -v python >/dev/null 2>&1; then
echo "Adding python to path"
Copy link
Member

Choose a reason for hiding this comment

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

NB: it would be cool to have a nix bash library for this kind of situation. I had added nix_debug / nix_info in pkgs/development/interpreters/lua-5/setup-hook.sh for instance (that act conditionnaly on NIX_DEBUG).

the indentation seems off.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
echo "Adding python to path"
echo "Adding python to path"

@veprbl
Copy link
Member

veprbl commented Sep 24, 2019

Why not move wafHook to pythonPackages as proposed in #69305?

@FRidh
Copy link
Member

FRidh commented Sep 24, 2019

@veprbl python-packages.nix is for libraries, not for anything for which we happen to want to have a version per interpreter.

@veprbl
Copy link
Member

veprbl commented Sep 24, 2019

@FRidh As far as I am concerned, waf is a library that allows you to create your own build system. Yes, you have to use their executable as an entry point and don't do explicit imports in most of the cases, but it still acts as a library.

@teto
Copy link
Member

teto commented Oct 11, 2019

what's the status of this ? I would like to convince ns-3 folks to try nix (they have lots of problem with the different dependency interactions that could be solved with nix) and this is kinda blocking.

@FRidh FRidh added this to Needs review in Staging Nov 12, 2019
@FRidh FRidh self-assigned this Nov 14, 2019
substitutions = {
inherit waf;
python = python3;
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
python = python3;
inherit python;

Staging automation moved this from Needs review to Ready Nov 14, 2019
Copy link
Contributor

@doronbehar doronbehar left a comment

Choose a reason for hiding this comment

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

I too would like this to be merged - seems impactfull on closure size etc.

@doronbehar doronbehar mentioned this pull request Nov 15, 2019
10 tasks
@veprbl veprbl moved this from Ready to WIP in Staging Dec 28, 2019
Copy link
Contributor

@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.

I would argue for removing the fallback Python altogether. This kind of backwards incompatibility is trivial to fix and it will simplify the packaging.

@teto
Copy link
Member

teto commented Feb 14, 2020

@FRidh As far as I am concerned, waf is a library that allows you to create your own build system. Yes, you have to use their executable as an entry point and don't do explicit imports in most of the cases, but it still acts as a library.

Either that or removing the python fallback which feels hackish.
Either way we need to choose before 20.03. it's a simple problem.

@xbreak
Copy link
Contributor

xbreak commented Feb 22, 2020

@matthewbauer: Slightly off topic but since the change anyways require mass rebuild: Have you considered also making wafHook optionally dependent on waf itself as well? The recommendation from the author is for waf to be shipped with the project so I guess that's the case for most packages. If that's indeed the case in Nixpkgs the default wafHook could be provided without waf. This would then reduce the impact of future wafpackage updates.

@veprbl
Copy link
Member

veprbl commented Feb 23, 2020

@xbreak There is no need to piggyback things just because there is a mass rebuild. If you think that you need a certain change and you can implement it yourself, then do it and just submit it as a separate PR.

@teto
Copy link
Member

teto commented Feb 24, 2020

@xbreak has a point here, all waf project I know embed their own waf. If we don't consider waf as a library, making it optional from the hook forces the user to set a python version. It's a convolutad way of doing the equivalent of python3Packages.wafHook but less hackish than the current one.

@stale

This comment has been minimized.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Aug 22, 2020
@FRidh
Copy link
Member

FRidh commented Aug 29, 2020

If that's indeed the case in Nixpkgs the default wafHook could be provided without waf. This would then reduce the impact of future wafpackage updates.

It is slightly different than how we work with hooks typically, but to me this seems like the best solution proposed thus far.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Aug 29, 2020
@veprbl
Copy link
Member

veprbl commented Aug 29, 2020

If that's indeed the case in Nixpkgs the default wafHook could be provided without waf. This would then reduce the impact of future wafpackage updates.

I'm not sure I understand what is being proposed here. Do I understand correctly, that this will result in the following two options:

  1. nativeBuildInputs = [ wafHook waf ]; for when we use waf from nixpkgs
nativeBuildInputs = [ wafHook python ];
wafPath = "./waf";

?

And then a more explicitly coupled way could look like:

  1. nativeBuildInputs = [ wafHook ];
  2. nativeBuildInputs = [ (wafHook.override { waf = "./waf"; }) ];

@FRidh
Copy link
Member

FRidh commented Aug 29, 2020

@veprbl right that's how I see it.

@ryantm ryantm marked this pull request as draft October 23, 2020 03:05
@eyJhb
Copy link
Member

eyJhb commented Oct 28, 2020

Any status on this, ns-3 really needs an update and relies on this (being something) getting merged.

@veprbl
Copy link
Member

veprbl commented Oct 28, 2020

@eyJhb Would you like to finish this?

@eyJhb
Copy link
Member

eyJhb commented Oct 28, 2020

If I had the competences to do so, I really would! :)

@eyJhb eyJhb mentioned this pull request Oct 28, 2020
10 tasks
@veprbl veprbl mentioned this pull request Nov 23, 2020
10 tasks
@ajs124 ajs124 mentioned this pull request Nov 30, 2020
10 tasks
@dasJ dasJ mentioned this pull request Dec 10, 2020
10 tasks
@FRidh
Copy link
Member

FRidh commented Dec 17, 2020

Closing in favor of #106533.

@FRidh FRidh closed this Dec 17, 2020
Staging automation moved this from WIP to Done Dec 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Staging
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

8 participants