Re: [Nix-dev] break purity

[stewart mackenzie]

Hi Oliver,

Here is a minimal example stripped of all the other crap:

https://github.com/fractalide/recompilation

Cheers!

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Separate repository for autogenerated lists of urls and hashes

[Freddy Rietdijk]

Autogenerating packages is one step further. But it would be nice if there
was one source where you could get more of such data from. Maybe
https://libraries.io/ some day?

To come back to the main topic, autogenerated lists in Nixpkgs. I could
imagine it would be nice if we would have also, next to `pkgs` and `lib`, a
`srcs`. This you could use to select the source archive of a package for a
certain version. For example, `src = fetchurl
srcs.github.${name}.${version}` or `src = fetchurl
srcs.pypi.${name}.${version} but also `meta = srcs.pypi.${name}.meta`.

On Sun, Apr 24, 2016 at 7:11 PM, Kosyrev Serge <_deepf...@feelingofgreen.ru>
wrote:

> Marc Weber  writes:
> > I personally think that "autogenerating" packages is the next huge step
> > to be taken. This requires a database and dependency information for all
> > information.
> >
> > Then all distros can benefit, not just nixos.org
>
> ..and share the maintenance burden..
>
> Which would raise more centralisation-related questions, but those would
> be problems we'd be happy to have, I think.. : -)
>
> --
> с уважениeм / respectfully,
> Косырев Сергей
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[Oliver Charles]

I'm afraid I don't really know what I'm looking at. Can you provide a
smaller self-contained example that I can look at?

On Sat, Apr 23, 2016 at 8:48 PM stewart mackenzie 
wrote:

> Okay, I'm having a few problems implementing this, if you wouldn't
> mind taking a look at this please:
>
> This is the package level default.nix which calls
> `buildFractalideComponent`: http://nixpaste.lbr.uno/ZTwRzV0-?nix
> Typically found here:
>
> https://github.com/fractalide/fractalide/blob/master/components/drop/ip/default.nix
>
> Here is the implementation of `buildFractalideComponent.nix`:
> http://nixpaste.lbr.uno/GmbsNjmk?nix
> Found here:
> https://github.com/fractalide/fractalide/blob/master/build-support/buildFractalideComponent.nix
>
> Here's my error message:
>
> [stewart@rivergod:~/dev/fractalide/fractalide]$ nix-build --argstr
> debug true -A components.drop_ip
> error: value is a function while a set was expected, at
>
> /home/stewart/dev/fractalide/fractalide/components/drop/ip/default.nix:15:21
> (use ‘--show-trace’ to show detailed location information)
>
> The error arises on the last line of default.nix
>
> /sjm
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] fix build for some kde-5 components

[Karn Kallio]

On Sun, 24 Apr 2016 11:10:07 +0100
Tomasz Czyż  wrote:

> Karn: why not just PR on github?
> 

github is not interesting.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] fix build for some kde-5 components

[Thomas Tuegel]

Karn,

Which version of Phonon is putting the includes in
"$out/include/phonon"? That's definitely a bug.

On Sat, Apr 23, 2016 at 9:14 PM, Karn Kallio
 wrote:
>
> Several phonon include paths reference the nonexistent include
> directory "Phonon" which breaks the kde5 build.  The attached patch
> fixes these replacing them with the correct "phonon" include directory.
>
> The phonon expression itself produces a "phonon" include directory, so
> I have used that as the definition of correct.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
Thomas Tuegel
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[Tomasz Czyż]

Hey Stewart, do you have any description of what you are exactly talking
about?

Personally I'm not following all the changes in packaging. If you could
describe the key differences or just put some github links to show them
that would be great.

2016-04-23 20:06 GMT+01:00 stewart mackenzie :

> Every time I come into contact with Peter Simon's work on Haskell I
> find myself growing green with envy.
>
> This approach seems to be a much better way of structuring nixpkgs in
> general.
>
> Now closure-size, a monumental job was undertaken successfully, what's
> the feasibility of implementing the Haskell approach across the entire
> nixpkgs.
>
> How does one even start thinking about this?
>
> Is it even worth it?
>
> /sjm
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] fix build for some kde-5 components

[Tomasz Czyż]

Karn: why not just PR on github?

2016-04-24 3:14 GMT+01:00 Karn Kallio :

>
> Several phonon include paths reference the nonexistent include
> directory "Phonon" which breaks the kde5 build.  The attached patch
> fixes these replacing them with the correct "phonon" include directory.
>
> The phonon expression itself produces a "phonon" include directory, so
> I have used that as the definition of correct.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>


-- 
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Separate repository for autogenerated lists of urls and hashes

[Marc Weber]

I personally think that "autogenerating" packages is the next huge step
to be taken. This requires a database and dependency information for all
information.

Then all distros can benefit, not just nixos.org

Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Separate repository for autogenerated lists of urls and hashes

[Freddy Rietdijk]

Hi,

Autogenerating lists with urls and hashes has been discussed before
[1,2,3], but I like to bring it up again as I'm working on autogenerating a
list with urls and hashes for Python's PyPI packages along with other meta
data [4].

At this point I chose to only retrieve data for specific packages instead
of all of PyPI. I think that's the sensible thing to do do since PyPI
contains a lot of junk. Even so, the autogenerated list with urls, hashes
and meta data can become quite large, especially as I chose to retrieve the
data for all versions of a package.

What I propose is that we split Nixpkgs basically in two, we keep Nixpkgs
that contains expressions, and we create another repository, Nixsrcs, that
contains scripts and autogenerated lists. These autogenerated lists will
contain *all* versions of a package. Nixpkgs would import these lists as
derivations (so we do need one small autogenerated list in Nixpkgs).

When building packages we can optionally specify a version. If a version is
not specified the latest available version will be built. Likely we do need
to limit somewhat the amount of versions in the autogenerated lists, but
that is something we need to find out. One nice feature to have is version
comparison, so we can just write the major version and let Nix determine
the latest minor version.

What do you think? Can it be done? Am I missing something? I guess it's a
matter of 'just doing'.

Freddy



[1] https://github.com/NixOS/nixpkgs/issues/14897
[2] http://thread.gmane.org/gmane.linux.distributions.nixos/18932
[3] http://thread.gmane.org/gmane.linux.distributions.nixos/18595
[4] https://github.com/NixOS/nixpkgs/pull/14927
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev