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

[RFC 0010] Nixpkgs development support #10

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy
Member

shlevy commented Apr 4, 2017

@edolstra

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra Apr 4, 2017

Member

This sounds like it could easily become a dumping ground of random crap. What would be the inclusion criteria? The alternative - using separate repositories - seems fine for development since people can use builtins.fetchgit to get them. If some tool becomes popular, it can always be merged into the Nixpkgs repo.

Also, I'm afraid builtins.exec may become a Pandora's box turning Nix into an imperative language.

Member

edolstra commented Apr 4, 2017

This sounds like it could easily become a dumping ground of random crap. What would be the inclusion criteria? The alternative - using separate repositories - seems fine for development since people can use builtins.fetchgit to get them. If some tool becomes popular, it can always be merged into the Nixpkgs repo.

Also, I'm afraid builtins.exec may become a Pandora's box turning Nix into an imperative language.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

I'm reluctant to assume the availability of builtins.fetchgit until 1.12 is released.

We don't have explicit inclusion criteria elsewhere in nixpkgs, do we? It should be something generally usefuil and maintainable and up to basic standards of code cleanliness.

Alternate repositories can't be kept in tight lockstep with nixpkgs. This is why we have nixos in nixpkgs, right?

builtins.exec is only turned on if you ask for it, and it solves some significant real problems. Do you have an alternative?

Member

shlevy commented Apr 4, 2017

I'm reluctant to assume the availability of builtins.fetchgit until 1.12 is released.

We don't have explicit inclusion criteria elsewhere in nixpkgs, do we? It should be something generally usefuil and maintainable and up to basic standards of code cleanliness.

Alternate repositories can't be kept in tight lockstep with nixpkgs. This is why we have nixos in nixpkgs, right?

builtins.exec is only turned on if you ask for it, and it solves some significant real problems. Do you have an alternative?

@edolstra

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra Apr 4, 2017

Member

Another issue: How does this differ from pkgs/build-support?

Member

edolstra commented Apr 4, 2017

Another issue: How does this differ from pkgs/build-support?

Any tool relying on `builtins.exec` will take that function as an
argument, rather than using the builtin directly, so that all of
nixpkgs evaluates properly without
`allow-unsafe-native-code-during-evaluation`.

This comment has been minimized.

@edolstra

edolstra Apr 4, 2017

Member

I don't see why this is necessary.

@edolstra

edolstra Apr 4, 2017

Member

I don't see why this is necessary.

This comment has been minimized.

@shlevy

shlevy Apr 4, 2017

Member

It makes it possible with a grep (possibly even enforced before merging) that nothing you build in nixpkgs can cause a problem if you have allow-unsafe-native-code-during-evaluation on.

@shlevy

shlevy Apr 4, 2017

Member

It makes it possible with a grep (possibly even enforced before merging) that nothing you build in nixpkgs can cause a problem if you have allow-unsafe-native-code-during-evaluation on.

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

@edolstra build-support is useful things that help nix builds. development-support is mostly evaluation time stuff.

Member

shlevy commented Apr 4, 2017

@edolstra build-support is useful things that help nix builds. development-support is mostly evaluation time stuff.

@copumpkin

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 4, 2017

Member

I think it's partly about discoverability and partly about co-versioned-ness. In many ways the closer analog to what you're talking about feels like the maintainers folder and possibly @aszlig's md5 collision abomination. These both strongly suggest to me that we want tooling for working on the nixpkgs repo, and want many of the goodies that Nix provides when working on Nixpkgs itself

Member

copumpkin commented Apr 4, 2017

I think it's partly about discoverability and partly about co-versioned-ness. In many ways the closer analog to what you're talking about feels like the maintainers folder and possibly @aszlig's md5 collision abomination. These both strongly suggest to me that we want tooling for working on the nixpkgs repo, and want many of the goodies that Nix provides when working on Nixpkgs itself

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy

shlevy Apr 4, 2017

Member

@copumpkin Want to coauthor?

Member

shlevy commented Apr 4, 2017

@copumpkin Want to coauthor?

@zimbatm zimbatm changed the title from Add nixpkgs-development-support RFC to [RFC 010] Add nixpkgs-development-support RFC Apr 4, 2017

@shlevy

This comment has been minimized.

Show comment
Hide comment
@shlevy
Member

shlevy commented Apr 6, 2017

@edolstra edolstra changed the title from [RFC 010] Add nixpkgs-development-support RFC to [RFC 010] Nixpkgs development support Apr 10, 2017

@zimbatm zimbatm changed the title from [RFC 010] Nixpkgs development support to [RFC 0010] Nixpkgs development support Apr 13, 2017

developers who use nix to manage their projects. With the merging of
the `builtins.exec` nix feature, there are a number of developer tools
I'd like to make widely available, such as something to translate a
.gitignore into a filterSource call or do no-sha256 fetchgit with

This comment has been minimized.

@michalrus
@michalrus
@0xABAB

This comment has been minimized.

Show comment
Hide comment
@0xABAB

0xABAB Jun 30, 2017

Another feature I would not want to see. Others have given enough arguments already.

0xABAB commented Jun 30, 2017

Another feature I would not want to see. Others have given enough arguments already.

@shlevy shlevy closed this Jan 19, 2018

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