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

[20.03] haskellPackages.geojson: unmark as broken #90677

Merged

Conversation

erictapen
Copy link
Member

This seems to build the whole time.

I've said it in the past but let this be one more datapoint in the discussion: Having to unmark packages annoys me (as a contributor) more than seeing a broken package fail every time I want to use it.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • 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 nixpkgs-review --run "nixpkgs-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.

@erictapen
Copy link
Member Author

Sorry for mass ping -.- I wrongly chose master as the base first.

@worldofpeace
Copy link
Contributor

Having to unmark packages annoys me (as a contributor) more than seeing a broken package fail every time I want to use it.

It's mainly for end users, so they don't have to compile a broken package etc. It can also easily be bypassed in several ways.

@worldofpeace worldofpeace merged commit 55ddbd2 into NixOS:release-20.03 Jun 17, 2020
@Profpatsch
Copy link
Member

I've said it in the past but let this be one more datapoint in the discussion: Having to unmark packages annoys me (as a contributor) more than seeing a broken package fail every time I want to use it.

It’s mostly for the hydra tbh; otherwise it would have to try to build every broken package every time somebody pushes a commit to nixpkgs.

@Profpatsch
Copy link
Member

But I agree with @worldofpeace, it’s super easy to wrap pkgs.haskell.lib.markUnbroken around your package, so we can have our cake and eat it, too.

It should be better documented how to mark packages as unbroken at the same time however.

@Profpatsch
Copy link
Member

cc @peti @cdepillabout @maralorn

@erictapen
Copy link
Member Author

@worldofpeace @Profpatsch I see your points here, especially the one about Hydra resource usage.

Still I want to emphasize that by fixing the problem on my side (e.g. by markUnbroken in my own repo), it becomes less likely for me to contribute upstream. As a low volume contributor I'm often in the situation where I ask myself wether it's worth it to create a completely different patch when the problem is already fixed on my side.

@maralorn
Copy link
Member

I don't think we can conceptually work around this. We have over 6000 packages from hackage marked as broken. Since there is no way to depublish anything on hackage, a lot of them are probably really of no relevance to anyone.
We need to compromise somewhere, but letting users run without a warning into compiling Haskell packages which then fail at any (possibley) very late point in the process, seems like a no-go for me.

What we should think about is better tooling. I had the idea about a database exposed via a webpage, that shows all haskellPackages and which of them are marked broken. Then in that list we could (if we had the build power) display if it builds despite the broken flag. (Maybe we could make this pull based? Offer a button to trigger a built?) And we could actually offer a button which creates a PR to remove the broken flag. Just toying around here, not sure when I would have the time to implement something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants