Skip to content

Add getComponent to project and package #1060

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

Merged
merged 7 commits into from
Mar 4, 2021
Merged

Conversation

hamishmack
Copy link
Collaborator

  • Delays cabal configure errors until after evaluation when possible.

  • Avoids rerunning long cabal configure if we already know it will fail.

  • Provides a way to get a component from a package or project using a cabal like reference.

Code using the tool functions will automatically use getComponent.

For (hackage-package {...}).components.library is also ok.

# Consider changing hackage-package use:
(pkgs.haskell-nix.hackage-package {...}).components.exes.something
(pkgs.haskell-nix.hackage-package {...}).getComponent "exe:something"

# For any cabal project:
project.hsPkgs.somepackage.components.exes.something
project.getComponent "somepackage:exe:something"
# or do it in two steps
(project.getPackage "somepackage").getComponent "exe:something"

The reason for the new function is that we cannot provide the attribute interface without knowing that packages are in the project first.

Here is how the cabal configure error output is handled:

  • The plan-nix derivation builds even if cabal configure fails.

  • When it fails, it copies failed-cabal-configure.nix to the $out/default.nix along with a copy of the cabal configure output.

  • When failed-cabal-configure.nix is imported and used in any way it writes the cabal configure output with __trace so it will always be visible.

  • Instead of a plan the imported nix contains a configurationError pointing the cabal configure output.

  • The intermediate functions configurationError and bubble it up to where it is needed.

  • getPackage returns a mostly empty proxy for a real package when there is a configurationError

  • The getComponent function always returns a derivation, but the version in the proxy writes the cabal configure output to stdout and calls exit 1 (so that it will never build).

* Delays cabal configure errors until after evaluation when possible.

* Avoids rerunning long `cabal configure` if we already know it will fail.

* Provides a way to get a component from a package or project using a `cabal` like reference.

Code using the `tool` functions will automatically use `getComponent`.

For `(hackage-package {...}).components.library` is also ok.

```
# Consider changing hackage-package use from:
(pkgs.haskell-nix.hackage-package {...}).components.exes.something
(pkgs.haskell-nix.hackage-package {...}).getComponent "exe:something"

# For any cabal project:
project.hsPkgs.somepackage.components.exes.something
project.getComponent "somepackage:exe:something"
# or do it in two steps
(project.getPackage "somepackage").getComponent "exe:something"
```

The reason for the new function is that we cannot provide the attribute interface without knowing that packages are in the project first.

Here is how the `cabal configure` error output is handled:

* The `plan-nix` derivation builds even if `cabal configure` fails.

* When it fails, it copies `failed-cabal-configure.nix` to the `$out/default.nix` along with a copy of the `cabal configure` output.

* When `failed-cabal-configure.nix` is imported and used in any way it writes the `cabal configure` output with `__trace` so it will always be visible.

* Instead of a `plan` the imported nix contains a `configurationError` pointing the `cabal configure` output.

* The intermediate functions `configurationError` and bubble it up to where it is needed.

* `getPackage` returns a mostly empty proxy for a real package when there is a `configurationError`

* The `getComponent` function always returns a derivation, but the version in the proxy writes the `cabal configure` output to stdout and calls `exit 1` (so that it will never build).
@hamishmack
Copy link
Collaborator Author

bors try

iohk-bors bot added a commit that referenced this pull request Mar 3, 2021
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 3, 2021

try

Build failed:

@hamishmack
Copy link
Collaborator Author

bors try

iohk-bors bot added a commit that referenced this pull request Mar 3, 2021
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 3, 2021

try

Timed out.

@hamishmack
Copy link
Collaborator Author

bors try

iohk-bors bot added a commit that referenced this pull request Mar 3, 2021
@hamishmack hamishmack mentioned this pull request Mar 3, 2021
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 4, 2021

try

Timed out.

Copy link
Collaborator

@angerman angerman left a comment

Choose a reason for hiding this comment

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

LGTM. I'm just a bit concerned about the disabling of all the targets (musl, ...)

@hamishmack
Copy link
Collaborator Author

I'm just a bit concerned about the disabling of all the targets (musl, ...)

Ooops, that was not supposed to be in here. Fixed

@hamishmack
Copy link
Collaborator Author

bors try

iohk-bors bot added a commit that referenced this pull request Mar 4, 2021
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 4, 2021

@hamishmack hamishmack merged commit 5c25ce9 into master Mar 4, 2021
@iohk-bors iohk-bors bot deleted the hkm/defer-errors branch March 4, 2021 07:11
booniepepper pushed a commit to booniepepper/haskell.nix that referenced this pull request Feb 4, 2022
* Delays cabal configure errors until after evaluation when possible.

* Avoids rerunning long `cabal configure` if we already know it will fail.

* Provides a way to get a component from a package or project using a `cabal` like reference.

Code using the `tool` functions will automatically use `getComponent`.

For `(hackage-package {...}).components.library` is also ok.

```
# Consider changing hackage-package use:
(pkgs.haskell-nix.hackage-package {...}).components.exes.something
(pkgs.haskell-nix.hackage-package {...}).getComponent "exe:something"

# For any cabal project:
project.hsPkgs.somepackage.components.exes.something
project.getComponent "somepackage:exe:something"
# or do it in two steps
(project.getPackage "somepackage").getComponent "exe:something"
```

The reason for the new function is that we cannot provide the attribute interface without knowing that packages are in the project first.

Here is how the `cabal configure` error output is handled:

* The `plan-nix` derivation builds even if `cabal configure` fails.

* When it fails, it copies `failed-cabal-configure.nix` to the `$out/default.nix` along with a copy of the `cabal configure` output.

* When `failed-cabal-configure.nix` is imported and used in any way it writes the `cabal configure` output with `__trace` so it will always be visible.

* Instead of a `plan` the imported nix contains a `configurationError` pointing the `cabal configure` output.

* The intermediate functions `configurationError` and bubble it up to where it is needed.

* `getPackage` returns a mostly empty proxy for a real package when there is a `configurationError`

* The `getComponent` function always returns a derivation, but the version in the proxy writes the `cabal configure` output to stdout and calls `exit 1` (so that it will never build).
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