Skip to content

Better support for file: urls in repositories #1915

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 1 commit into from
Apr 12, 2023
Merged

Conversation

michaelpj
Copy link
Collaborator

If you have a repository whose URL is a file: URL, then you will end
up with package sources being specified by fetchurl calls with file:
URLs. Now, in principle curl can fetch from file: URLs, but the Nix
sandbox isn't relaxed in the right way to allow it to see the file (just
the internet!). We can get around this by using builtins.path instead.

If you have a repository whose URL is a `file:` URL, then you will end
up with package sources being specified by `fetchurl` calls with `file:`
URLs. Now, in principle `curl` can fetch from `file:` URLs, but the Nix
sandbox isn't relaxed in the right way to allow it to see the file (just
the internet!). We can get around this by using `builtins.path` instead.
@michaelpj michaelpj requested a review from andreabedini April 11, 2023 15:36
Copy link
Member

@andreabedini andreabedini left a comment

Choose a reason for hiding this comment

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

LGTM. In the end it's mostly a workaround for fetchurl not dealing with file:// urls.

@hamishmack hamishmack merged commit e00f3ee into master Apr 12, 2023
@iohk-bors iohk-bors bot deleted the mpj/file-urls branch April 12, 2023 09:40
@andreabedini
Copy link
Member

I was just chatting with @michaelpj and there is some concern this might cause some non reproducibility. If the file:// uri points to the nix store, it might get GC'ed and the nix plan would not know how to re-create it.

@michaelpj
Copy link
Collaborator Author

I think I've mildly convinced myself it's okay. It won't bust the resulting derivation, since it will create a "proper" FOD immediately. Conceivably I think it could go wrong if there was a GC right in between evaluation and starting to build the derivations, perhaps 🤔

andreabedini added a commit to IntersectMBO/cardano-haskell-packages that referenced this pull request Apr 14, 2023
After #200 we started seeing CI failures including messages like "source not available" or "don't know how to build these paths".

AFAIU these could be consequence of the changes in input-output-hk/haskell.nix#1915 and/or input-output-hk/haskell.nix#1910.

To try to unblock this I am a adding the `--fallback` option to nix [1] which allows nix to build a derivation that fails the substitution. 🤞 

[1] https://nixos.org/manual/nix/stable/command-ref/opt-common.html#opt-fallback
lehins pushed a commit to IntersectMBO/cardano-haskell-packages that referenced this pull request Apr 14, 2023
* Release consensus 0.4

* Try to work around nix failures with --fallback

After #200 we started seeing CI failures including messages like "source not available" or "don't know how to build these paths".

AFAIU these could be consequence of the changes in input-output-hk/haskell.nix#1915 and/or input-output-hk/haskell.nix#1910.

To try to unblock this I am a adding the `--fallback` option to nix [1] which allows nix to build a derivation that fails the substitution. 🤞 

[1] https://nixos.org/manual/nix/stable/command-ref/opt-common.html#opt-fallback

* Revert "Rework builder to work with new haskell.nix (#200)"

This reverts commit 408c4f4.

---------

Co-authored-by: Andrea Bedini <[email protected]>
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.

3 participants