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: Fetch sources #34755

Closed
wants to merge 5 commits into from
Closed

WIP: Fetch sources #34755

wants to merge 5 commits into from

Conversation

zimbatm
Copy link
Member

@zimbatm zimbatm commented Feb 8, 2018

Motivation for this change

This is a revival of #19582 but simplified to try to simplify the package update scenario.

The PR also contains an example script adapted from @layus' idea to demonstrate why fetchSource could be nice.

The idea is that you would run nix edit nixpkgs.hello, update the version or whatever. Then nix-update-src hello to prefetch-url and replace the sha256 directly. This could be combined in a nix-edit, update, build loop further down the road.

At this point I am looking for feedback on the idea and naming.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-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 nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

easy multi-arch support
nix-prefetch-url, but that directly replaces the sha256 in the file

nix edit

supports fetchSources

TODO: support all the `nix edit` options
@grahamc
Copy link
Member

grahamc commented Feb 9, 2018

I like the idea. The script should probably be located in maintainer/scripts, and perhaps it would be good to put a comment in places that fetchSource is used to remind people the script is there / how to use it.

@Mic92
Copy link
Member

Mic92 commented Feb 9, 2018

There is a different package called: common-updater in nixpkgs. I think we should have only one of the two in our repo. Update both might serve a slightly different purpose.

@layus
Copy link
Member

layus commented Feb 9, 2018

Two questions:

  1. why require -f . by default
  2. Why do you use fetchSource in mplayer.nix when the codecs_src attribute cannot be accessed by the update script anyway ?

@zimbatm
Copy link
Member Author

zimbatm commented Feb 9, 2018

the updater script is only there to illustrate the possibility for now. It could be cannibalized or moved to a different repo. The important part is to have access to all the fetchurl instances regardless of the tool.

I think fetchSources should be tried of a few other things before being merged. I am also not quite sure of the naming yet.

@Mic92
Copy link
Member

Mic92 commented Feb 9, 2018

Just for related work, I also post this project here: https://github.com/makefu/nix-src-updater

@layus
Copy link
Member

layus commented Feb 9, 2018

There is a different package called: common-updater in nixpkgs. I think we should have only one of the two in our repo.

Indeed. We should update that one. The main advantage of this script is that it locates the file to edit without the need of a .meta.position field.

@zimbatm
Copy link
Member Author

zimbatm commented Feb 9, 2018

@layus I tried to mimic the UX of nix edit. The script doesn't work since I changed it because nix-prefetch-url doesn't understand this notation.

@layus
Copy link
Member

layus commented Feb 9, 2018

the updater script is only there to illustrate the possibility for now. It could be cannibalized or moved to a different repo. The important part is to have access to all the fetchurl instances regardless of the tool.

Okay, I was already going too far :-). fetchSources is a good name, and I like the concept.

Other idea: Why not automatically detect the right source, or provide a fetchSystemSource function ?

I think fetchSources should be tried of a few other things before being merged. I am also not quite sure of the naming yet.

May I suggest factorio ?

@oxij
Copy link
Member

oxij commented Feb 9, 2018 via email

@zimbatm
Copy link
Member Author

zimbatm commented Feb 12, 2018

It looks like fetchSource could just be a lib function since it's not depending on stdenv. How about:
lib.select attrs key and lib.selectSystem {}. The only issue is that it assumes that the return value is an attrset and is okay to override the selections keys, not sure what to do about that.

@oxij
Copy link
Member

oxij commented Feb 17, 2018 via email

@oxij
Copy link
Member

oxij commented Feb 17, 2018

@zimbatm The problem with not depending on stdenv is that select then becomes so trivial that it only wastes space. I would do attrs.${key} instead.

Lets discuss the proper name here and then I will steal the fixed eb77c08 to #35075 because I really need it there.

@7c6f434c
Copy link
Member

If I understand correctly, the point is to add the list of the alternative downloads as an attribute of the chosen one.

@oxij
Copy link
Member

oxij commented Feb 17, 2018

That too, but I don't care about that part, I care about the syntax. fetchSources from here is much prettier than expressions soiled with optionalAttrs hack from 37dedf64536f366df730584b5fb285b0469d2bea.

@oxij
Copy link
Member

oxij commented Feb 17, 2018

Ah, I have a better idea for both here and my PR: I will implement attrByName, which would be like attrByPath but without the path. This is what @zimbatm actually wants, and what I need to make my srcs pretty. Gone hacking.

@zimbatm
Copy link
Member Author

zimbatm commented Feb 20, 2018

As long as the original attribute set is still accessible somehow it's fine by me

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

8 participants