Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Luca Bruno]

I don't like the idea. It's a mess. It's a mess for people maintaining
environments, like kde or gnome.

So I propose to still have directories, but chosen by maintainers. For
example I don't want all the gnome3 packages to be in a flattened directory
together with everything else.
Pretty sure the same applies to our toolchain and base system tools, or
kernel stuff, kde, Xorg stuff, ecc.


On Fri, Jan 8, 2016 at 1:04 AM, Tomasz Czyż  wrote:

> After playing for a while with a nixpkgs repo I have impression that
> categories/directories are just waste of time.
>
> * Have to be maintained
> * Harder to find things
> * Lack of any package manager which tells about it
>
> Each time I want to find a package name I do
> * find -name '*name*'
> or use github search to locate files in repo.
>
> From maintaining perspective:
>
> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
> 1 - backup
> 2 - inferno
> 2 - search
> 3 - gis
> 4 - display-managers
> 10 - altcoins
> 11 - science
> 11 - taxes
> 20 - virtualization
> 25 - kde-apps-15.12
> 27 - office
> 41 - version-management
> 41 - window-managers
> 42 - networking
> 59 - video
> 60 - editors
> 85 - graphics
> 186 - audio
> 224 - misc
>
> Do you see that? It's hard to define all those categories levels, some of
> directories have subdirectories (like applications) other not (servers).
> It's hard to follow.
> Most people know the name of the software, if not, they probably use
> google to find it, not using categories.
>
> Let's make the layout more clear, more accessible and easy to follow.
>
> What do you think about moving all packages into flat namespace?
>
> Let's say you have
>
> pkgs/package1/default.nix
> pkgs/package2/default.nix
>
> or even better:
>
> pkgs/my-package.nix
> pkgs/gcc.nix
> pkgs/gcc-5.0.nix
>
> then, you can autogenerate top-level.pkgs
>
> I'm happy to help implementing that.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>


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

Re: [Nix-dev] Configure WiFi networks for NetworkManager in configuration.nix?

[Mateusz Czaplinski]

Sent as https://github.com/NixOS/nixpkgs/pull/12219.

Thanks all for help!

/Mateusz.

On Thu, Jan 7, 2016 at 1:21 PM, Mateusz Czaplinski 
wrote:

> The `mode = "0400"` approach seems to work indeed, thanks! And just as you
> advised, the secret is then world-readable in /nix/store/*-etc/... and in
> /etc/nixos/configuration.nix anyway. I see the same issue was discussed in
> the aforementioned #12015 (
> https://github.com/NixOS/nixpkgs/pull/12015#discussion-diff-48864628),
> but it was apparently stepped over and accepted for the time being.
> Personally, I'm inclined to add some comment / "SECURITY WARNING" to both
> the manual and the option description in my forthcoming PR. That said, I'm
> sure interested in how /etc/shadow works if it could possibly be helpful
> here.
>
> As to other aspects, currently I'm reusing the
> "networking.wireless.networks" property from #12015 to build the simple
> WiFi config for network-manager. Is that a good way to go (+ modifying the
> comments in the config & manual to account for nm), or should I create a
> parallel option definition in e.g.
> "networking.networkmanager.wirelessNetworks" instead? Or should I go on and
> send the PR when ready and move that part of the discussion there?
>
> Thanks,
> /Mateusz.
>
> On Thu, Jan 7, 2016 at 12:45 PM, Tomasz Czyż 
> wrote:
>
>> So, how /etc/shadow file works? I did a quick look and seems it's
>> generated by some perl scripts (probably omitting nix store), is that
>> correct? Maybe the same way could be used here.
>>
>> 2016-01-06 15:03 GMT+00:00 Fabian Schmitthenner 
>> :
>>
>>> I think you can use
>>>
>>> environment.etc."NetworkManager/system-connections/some-file" = {
>>>   text = "Text of file";
>>>   mode = "0400";
>>> }
>>>
>>> This will copy the file into /etc with appropriate mode at activation
>>> time. See also http://nixos.org/nixos/options.html and search for
>>> environment.etc for further options.
>>>
>>> (Of cause other users can still read the original file in the nix store,
>>> so the contents would still be reachable for all users).
>>>
>>> Greetings
>>>
>>> Fabian
>>>
>>> On 01/06/2016 02:26 PM, Vladimír Čunát wrote:
>>> > On 01/06/2016 12:52 AM, Mateusz Czaplinski wrote:
>>> >> NetworkManager expects to have network definitions as chmod 400 files
>>> in
>>> >> /etc/NetworkManager/system-connections/ IIRC.
>>> >
>>> > Files in nix store can't be chmod 400.
>>> >
>>> > --Vladimir
>>> >
>>> >
>>> >
>>> >
>>> > ___
>>> > 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
>>>
>>>
>>
>>
>> --
>> Tomasz Czyż
>>
>> ___
>> 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] Flattening pkgs tree in nixpkgs/pkgs

[Profpatsch]

Full ack for flattening all-packages.nix.
I didn’t even know there where sections until a few days ago,
the file is simply too large.
Let’s just sort the top level by alphabet.

On 16-01-08 01:10am, Luca Bruno wrote:
> So I propose to still have directories, but chosen by maintainers. For
> example I don't want all the gnome3 packages to be in a flattened directory
> together with everything else.
> Pretty sure the same applies to our toolchain and base system tools, or
> kernel stuff, kde, Xorg stuff, ecc.

Folders should stay imo, but be considerably simplified. Of course the folder
stucture of frameworks should be decided upon by the maintainers.
It wouldn’t hurt to have a similar structure shared by all frameworks, though.

Now the problem is: Who has enough time to refactor everything? :)

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Tomasz Czyż]

2016-01-08 0:37 GMT+00:00 Mathnerd314 :

> On Thu, Jan 7, 2016 at 5:04 PM, Tomasz Czyż  wrote:
>
>> What do you think about moving all packages into flat namespace?
>>
>
> GitHub limits directories to 1000 files, for example here:
> https://github.com/rust-lang/rust/tree/master/src/test/run-pass
> We definitely have more than that in nixpkgs, so some form of hierarchy is
> needed.
>
LOL, didn't know about that.

>
> I would suggest doing it by hosting site / provider: all KDE packages in
> one directory, all GNOME in another, GNU in a third, SourceForge in a
> fourth, Kernel.org in a fifth, etc., with a final "misc" directory for
> one-package sites.
>
Looks like good way, but not sure about few things. So github.com whould be
another provider?
Seems like haskellPackages, pythonPackages, *Packages could follow that
rule if we treat lang-repos as providers.

>
> It does mean that packages have to be moved around when their hosting
> changes (e.g. VLC's move away from Sourceforge), but on the other hand it
> makes it very easy to find all broken packages when a site shuts down (e.g.
> Google Code). In general packages change hosting very infrequently, so it
> seems reasonable to me.
>
> The directory structure under that can be flat or chosen by maintainers.
>
> Search, nix-env, and command-not-found remain the best way of finding
> packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS.
>
Sorry I was not precise. The problem is to locate program nix file, not the
name/attribute.

>
> -- Mathenrd314
>



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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Jookia]

On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote:
> 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy :
> Still don't see the value in it. I would just prefix them with
> haskellPackages-, pythonPackages-.

How would we do something like 'buildInputs = with pythonPackages; [pycrypto]; '
with that kind of system? I imagine things would get very verbose very quickly.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Jonn Mostovoy]

Your approach holds for applications, but fails for libraries, or rather,
for packages that are part of different ecosystems.

There are some packages that just can't be taken out of their respective
"contexts" without introducing indirection.

I agree, however, that "packages in themselves" *can* be flattened, I'm not
sure they should be though. Giving an option for a user to go over
interesting to him parts of nixpkgs over tea, clicking with mouse and
scrolling, learning about what's packaged and what's not might be not worth
taking away.
On Jan 8, 2016 1:04 AM, "Tomasz Czyż"  wrote:

> After playing for a while with a nixpkgs repo I have impression that
> categories/directories are just waste of time.
>
> * Have to be maintained
> * Harder to find things
> * Lack of any package manager which tells about it
>
> Each time I want to find a package name I do
> * find -name '*name*'
> or use github search to locate files in repo.
>
> From maintaining perspective:
>
> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
> 1 - backup
> 2 - inferno
> 2 - search
> 3 - gis
> 4 - display-managers
> 10 - altcoins
> 11 - science
> 11 - taxes
> 20 - virtualization
> 25 - kde-apps-15.12
> 27 - office
> 41 - version-management
> 41 - window-managers
> 42 - networking
> 59 - video
> 60 - editors
> 85 - graphics
> 186 - audio
> 224 - misc
>
> Do you see that? It's hard to define all those categories levels, some of
> directories have subdirectories (like applications) other not (servers).
> It's hard to follow.
> Most people know the name of the software, if not, they probably use
> google to find it, not using categories.
>
> Let's make the layout more clear, more accessible and easy to follow.
>
> What do you think about moving all packages into flat namespace?
>
> Let's say you have
>
> pkgs/package1/default.nix
> pkgs/package2/default.nix
>
> or even better:
>
> pkgs/my-package.nix
> pkgs/gcc.nix
> pkgs/gcc-5.0.nix
>
> then, you can autogenerate top-level.pkgs
>
> I'm happy to help implementing that.
>
> ___
> 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] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 6:25 PM, Jookia <166...@gmail.com> wrote:

> On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote:
> > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy :
> > Still don't see the value in it. I would just prefix them with
> > haskellPackages-, pythonPackages-.
>
> How would we do something like 'buildInputs = with pythonPackages;
> [pycrypto]; '
> with that kind of system? I imagine things would get very verbose very
> quickly.
>

We would still have all-packages.nix, so the attribute paths would not
change.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Tomasz Czyż]

@Luca:
Why haproxy is more a tool and sigproxd is more application than tool?
./tools/networking/haproxy
./applications/networking/siproxd
Why there is no common networking category? (simple, because most programs
match multiple categories)

Same for "groups", why gnome-terminal is more gnome and not more terminal?

@Jonn
Could you give an example? I'm using nix ~0.5year and not familiar with all
internals yet.

2016-01-08 0:15 GMT+00:00 Jonn Mostovoy :

> Your approach holds for applications, but fails for libraries, or rather,
> for packages that are part of different ecosystems.
>
> There are some packages that just can't be taken out of their respective
> "contexts" without introducing indirection.
>
> I agree, however, that "packages in themselves" *can* be flattened, I'm
> not sure they should be though. Giving an option for a user to go over
> interesting to him parts of nixpkgs over tea, clicking with mouse and
> scrolling, learning about what's packaged and what's not might be not worth
> taking away.
> On Jan 8, 2016 1:04 AM, "Tomasz Czyż"  wrote:
>
>> After playing for a while with a nixpkgs repo I have impression that
>> categories/directories are just waste of time.
>>
>> * Have to be maintained
>> * Harder to find things
>> * Lack of any package manager which tells about it
>>
>> Each time I want to find a package name I do
>> * find -name '*name*'
>> or use github search to locate files in repo.
>>
>> From maintaining perspective:
>>
>> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
>> 1 - backup
>> 2 - inferno
>> 2 - search
>> 3 - gis
>> 4 - display-managers
>> 10 - altcoins
>> 11 - science
>> 11 - taxes
>> 20 - virtualization
>> 25 - kde-apps-15.12
>> 27 - office
>> 41 - version-management
>> 41 - window-managers
>> 42 - networking
>> 59 - video
>> 60 - editors
>> 85 - graphics
>> 186 - audio
>> 224 - misc
>>
>> Do you see that? It's hard to define all those categories levels, some of
>> directories have subdirectories (like applications) other not (servers).
>> It's hard to follow.
>> Most people know the name of the software, if not, they probably use
>> google to find it, not using categories.
>>
>> Let's make the layout more clear, more accessible and easy to follow.
>>
>> What do you think about moving all packages into flat namespace?
>>
>> Let's say you have
>>
>> pkgs/package1/default.nix
>> pkgs/package2/default.nix
>>
>> or even better:
>>
>> pkgs/my-package.nix
>> pkgs/gcc.nix
>> pkgs/gcc-5.0.nix
>>
>> then, you can autogenerate top-level.pkgs
>>
>> I'm happy to help implementing that.
>>
>> ___
>> 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

[Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Tomasz Czyż]

After playing for a while with a nixpkgs repo I have impression that
categories/directories are just waste of time.

* Have to be maintained
* Harder to find things
* Lack of any package manager which tells about it

Each time I want to find a package name I do
* find -name '*name*'
or use github search to locate files in repo.

>From maintaining perspective:

(for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
1 - backup
2 - inferno
2 - search
3 - gis
4 - display-managers
10 - altcoins
11 - science
11 - taxes
20 - virtualization
25 - kde-apps-15.12
27 - office
41 - version-management
41 - window-managers
42 - networking
59 - video
60 - editors
85 - graphics
186 - audio
224 - misc

Do you see that? It's hard to define all those categories levels, some of
directories have subdirectories (like applications) other not (servers).
It's hard to follow.
Most people know the name of the software, if not, they probably use google
to find it, not using categories.

Let's make the layout more clear, more accessible and easy to follow.

What do you think about moving all packages into flat namespace?

Let's say you have

pkgs/package1/default.nix
pkgs/package2/default.nix

or even better:

pkgs/my-package.nix
pkgs/gcc.nix
pkgs/gcc-5.0.nix

then, you can autogenerate top-level.pkgs

I'm happy to help implementing that.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Jonn Mostovoy]

Tomasz,

Any group of packages that depend on a runtime or maintained as whole for
different reasons.

Kde, Gnome, haskellPackages.

In fact, go through the directory tree and read some deep expressions,
you'll see the usefulness of it yourself!

You are complaining about ambiguity in categories, why not to add more
dimensions to the metadata and utility to query values of those? Some
categories are better than no categories, are better than some things
categorized and some others not categorized.
On Jan 8, 2016 1:21 AM, "Tomasz Czyż"  wrote:

> @Luca:
> Why haproxy is more a tool and sigproxd is more application than tool?
> ./tools/networking/haproxy
> ./applications/networking/siproxd
> Why there is no common networking category? (simple, because most programs
> match multiple categories)
>
> Same for "groups", why gnome-terminal is more gnome and not more terminal?
>
> @Jonn
> Could you give an example? I'm using nix ~0.5year and not familiar with
> all internals yet.
>
> 2016-01-08 0:15 GMT+00:00 Jonn Mostovoy :
>
>> Your approach holds for applications, but fails for libraries, or rather,
>> for packages that are part of different ecosystems.
>>
>> There are some packages that just can't be taken out of their respective
>> "contexts" without introducing indirection.
>>
>> I agree, however, that "packages in themselves" *can* be flattened, I'm
>> not sure they should be though. Giving an option for a user to go over
>> interesting to him parts of nixpkgs over tea, clicking with mouse and
>> scrolling, learning about what's packaged and what's not might be not worth
>> taking away.
>> On Jan 8, 2016 1:04 AM, "Tomasz Czyż"  wrote:
>>
>>> After playing for a while with a nixpkgs repo I have impression that
>>> categories/directories are just waste of time.
>>>
>>> * Have to be maintained
>>> * Harder to find things
>>> * Lack of any package manager which tells about it
>>>
>>> Each time I want to find a package name I do
>>> * find -name '*name*'
>>> or use github search to locate files in repo.
>>>
>>> From maintaining perspective:
>>>
>>> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
>>> 1 - backup
>>> 2 - inferno
>>> 2 - search
>>> 3 - gis
>>> 4 - display-managers
>>> 10 - altcoins
>>> 11 - science
>>> 11 - taxes
>>> 20 - virtualization
>>> 25 - kde-apps-15.12
>>> 27 - office
>>> 41 - version-management
>>> 41 - window-managers
>>> 42 - networking
>>> 59 - video
>>> 60 - editors
>>> 85 - graphics
>>> 186 - audio
>>> 224 - misc
>>>
>>> Do you see that? It's hard to define all those categories levels, some
>>> of directories have subdirectories (like applications) other not (servers).
>>> It's hard to follow.
>>> Most people know the name of the software, if not, they probably use
>>> google to find it, not using categories.
>>>
>>> Let's make the layout more clear, more accessible and easy to follow.
>>>
>>> What do you think about moving all packages into flat namespace?
>>>
>>> Let's say you have
>>>
>>> pkgs/package1/default.nix
>>> pkgs/package2/default.nix
>>>
>>> or even better:
>>>
>>> pkgs/my-package.nix
>>> pkgs/gcc.nix
>>> pkgs/gcc-5.0.nix
>>>
>>> then, you can autogenerate top-level.pkgs
>>>
>>> I'm happy to help implementing that.
>>>
>>> ___
>>> 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] Flattening pkgs tree in nixpkgs/pkgs

[Tomasz Czyż]

2016-01-08 0:34 GMT+00:00 Jonn Mostovoy :

> Tomasz,
>
> Any group of packages that depend on a runtime or maintained as whole for
> different reasons.
>
> Kde, Gnome, haskellPackages.
>
Still don't see the value in it. I would just prefix them with
haskellPackages-, pythonPackages-.

> In fact, go through the directory tree and read some deep expressions,
> you'll see the usefulness of it yourself!
>
Will look thanks.

> You are complaining about ambiguity in categories, why not to add more
> dimensions to the metadata and utility to query values of those? Some
> categories are better than no categories, are better than some things
> categorized and some others not categorized.
>
I completely agree! I think all metadata should be in metadata attribute in
nix file :-)


> On Jan 8, 2016 1:21 AM, "Tomasz Czyż"  wrote:
>
>> @Luca:
>> Why haproxy is more a tool and sigproxd is more application than tool?
>> ./tools/networking/haproxy
>> ./applications/networking/siproxd
>> Why there is no common networking category? (simple, because most
>> programs match multiple categories)
>>
>> Same for "groups", why gnome-terminal is more gnome and not more terminal?
>>
>> @Jonn
>> Could you give an example? I'm using nix ~0.5year and not familiar with
>> all internals yet.
>>
>> 2016-01-08 0:15 GMT+00:00 Jonn Mostovoy :
>>
>>> Your approach holds for applications, but fails for libraries, or
>>> rather, for packages that are part of different ecosystems.
>>>
>>> There are some packages that just can't be taken out of their respective
>>> "contexts" without introducing indirection.
>>>
>>> I agree, however, that "packages in themselves" *can* be flattened, I'm
>>> not sure they should be though. Giving an option for a user to go over
>>> interesting to him parts of nixpkgs over tea, clicking with mouse and
>>> scrolling, learning about what's packaged and what's not might be not worth
>>> taking away.
>>> On Jan 8, 2016 1:04 AM, "Tomasz Czyż"  wrote:
>>>
 After playing for a while with a nixpkgs repo I have impression that
 categories/directories are just waste of time.

 * Have to be maintained
 * Harder to find things
 * Lack of any package manager which tells about it

 Each time I want to find a package name I do
 * find -name '*name*'
 or use github search to locate files in repo.

 From maintaining perspective:

 (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
 1 - backup
 2 - inferno
 2 - search
 3 - gis
 4 - display-managers
 10 - altcoins
 11 - science
 11 - taxes
 20 - virtualization
 25 - kde-apps-15.12
 27 - office
 41 - version-management
 41 - window-managers
 42 - networking
 59 - video
 60 - editors
 85 - graphics
 186 - audio
 224 - misc

 Do you see that? It's hard to define all those categories levels, some
 of directories have subdirectories (like applications) other not (servers).
 It's hard to follow.
 Most people know the name of the software, if not, they probably use
 google to find it, not using categories.

 Let's make the layout more clear, more accessible and easy to follow.

 What do you think about moving all packages into flat namespace?

 Let's say you have

 pkgs/package1/default.nix
 pkgs/package2/default.nix

 or even better:

 pkgs/my-package.nix
 pkgs/gcc.nix
 pkgs/gcc-5.0.nix

 then, you can autogenerate top-level.pkgs

 I'm happy to help implementing that.

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


>>
>>
>> --
>> Tomasz Czyż
>>
>


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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 5:04 PM, Tomasz Czyż  wrote:

> What do you think about moving all packages into flat namespace?
>

GitHub limits directories to 1000 files, for example here:
https://github.com/rust-lang/rust/tree/master/src/test/run-pass
We definitely have more than that in nixpkgs, so some form of hierarchy is
needed.

I would suggest doing it by hosting site / provider: all KDE packages in
one directory, all GNOME in another, GNU in a third, SourceForge in a
fourth, Kernel.org in a fifth, etc., with a final "misc" directory for
one-package sites.

It does mean that packages have to be moved around when their hosting
changes (e.g. VLC's move away from Sourceforge), but on the other hand it
makes it very easy to find all broken packages when a site shuts down (e.g.
Google Code). In general packages change hosting very infrequently, so it
seems reasonable to me.

The directory structure under that can be flat or chosen by maintainers.

Search, nix-env, and command-not-found remain the best way of finding
packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 5:44 PM, Tomasz Czyż  wrote:

> 2016-01-08 0:37 GMT+00:00 Mathnerd314 :
>
>>
>> I would suggest doing it by hosting site / provider: all KDE packages in
>> one directory, all GNOME in another, GNU in a third, SourceForge in a
>> fourth, Kernel.org in a fifth, etc., with a final "misc" directory for
>> one-package sites.
>>
> Looks like good way, but not sure about few things. So github.com whould
> be another provider?
> Seems like haskellPackages, pythonPackages, *Packages could follow that
> rule if we treat lang-repos as providers.
>
Yeah, language specific stuff should be their own directories.
GitHub/SF/etc. are catch-alls; in theory there could be 1000's of projects
from them, but in practice it seems that most of the projects on there are
dead, abandoned, or mirrored somewhere else.

The goal is to have a unique location for each package, so that two people
don't package the same thing twice (which has already happened a few times
with our current structure). Hosting seems like a good index but there
might be something else (month project was founded?).

Search, nix-env, and command-not-found remain the best way of finding
>> packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS.
>>
> Sorry I was not precise. The problem is to locate program nix file, not
> the name/attribute.
>
Well, once you have the attribute it is usually not too hard to find the
file by tracing through the code.

And some packages are spread across multiple files, e.g. kde4.okular has
the source hash in pkgs/desktops/kde-4.14/kde-package/4.14.3.nix, the
description in pkgs/desktops/kde-4.14/kdegraphics/okular.nix, and the glue
code in pkgs/desktops/kde-4.14/kde-package/default.nix. Keeping all the
relevant files in one directory seems like the most one could ask for.

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

Re: [Nix-dev] Configure WiFi networks for NetworkManager in configuration.nix?

[Tomasz Czyż]

So, how /etc/shadow file works? I did a quick look and seems it's generated
by some perl scripts (probably omitting nix store), is that correct? Maybe
the same way could be used here.

2016-01-06 15:03 GMT+00:00 Fabian Schmitthenner :

> I think you can use
>
> environment.etc."NetworkManager/system-connections/some-file" = {
>   text = "Text of file";
>   mode = "0400";
> }
>
> This will copy the file into /etc with appropriate mode at activation
> time. See also http://nixos.org/nixos/options.html and search for
> environment.etc for further options.
>
> (Of cause other users can still read the original file in the nix store,
> so the contents would still be reachable for all users).
>
> Greetings
>
> Fabian
>
> On 01/06/2016 02:26 PM, Vladimír Čunát wrote:
> > On 01/06/2016 12:52 AM, Mateusz Czaplinski wrote:
> >> NetworkManager expects to have network definitions as chmod 400 files in
> >> /etc/NetworkManager/system-connections/ IIRC.
> >
> > Files in nix store can't be chmod 400.
> >
> > --Vladimir
> >
> >
> >
> >
> > ___
> > 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
>
>


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

[Nix-dev] How do I include patches when using pkgs.linuxPackages_custom?

[Tim Dempsey]

Hello,

i have added the following, base on
https://nixos.org/wiki/How_to_tweak_Linux_kernel_config_options, to my
/etc/nixos/configuration.nix.

  boot.kernelPackages  = pkgs.linuxPackages_custom {
version = "4.4.0-rc5";
src = pkgs.fetchurl {
  url =
"mirror://kernel/linux/kernel/v4.x/testing/linux-4.4-rc5.tar.xz";
  sha256 = "0qr1a8nmq6csbsw4cbqnn3m37a0fapj7a7cm9vj7fy7kq1rgxkpb";
};
configfile = /etc/nixos/kernel-4.4.0-rc5/kernel-4.4.0-rc5.config;
  };

ran *nixos-rebuild switch* and got a shiny new kernel. Based on the same
wiki page, I then added the following to my configuration.nix file hoping
to apply kernel patches to the new kernel.

 nixpkgs.config = {
   packageOverrides = pkgs: {
 stdenv = pkgs.stdenv // {
   platform = pkgs.stdenv.platform // {
 kernelPatches = [
  { patch=/etc/nixos/kernel-4.4.0-rc5/01_check_fwnode_type.patch;
name="yoga900_01"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/02_rename_is.to_pset.patch;
name="yoga900_02"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/03_refactor_builtin_prop.patch;
name="yoga900_03"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/04_keep_single_value.patch;
name="yoga900_04"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/05_helper_macro_prop.patch;
name="yoga900_05"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/06_improve_readability.patch;
name="yoga900_06"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/07_prop_not_found_ret_EINVAL.patch;
name="yoga900_07"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/08_fallback-2_sec_fwnode.patch;
name="yoga900_08"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/09_take_copy_prop_set.patch;
name="yoga900_09"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/10_supp_builtin_prop.patch;
name="yoga900_10"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/11_dont_overwrite_sce_fwnode.patch;
name="yoga900_11"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/12_propagate_dev_prop_2_sub.patch;
name="yoga900_12"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/13_pass_dev_params_supp.patch;
name="yoga900_13"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/14_pass_sda_hold_time.patch;
name="yoga900_14"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/15_pass_uart_conf.patch;
name="yoga900_16"; }
  { patch=/etc/nixos/kernel-4.4.0-rc5/16_convert_unified_dev_prop.patch;
name="yoga900_16"; }
 ];
   };
 };
   };
  };
 but running *nixos-rebuild switch* produced no changes and no errors. How
do I include patches when using pkgs.linuxPackages_custom to build a custom
kernel?

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

[Nix-dev] Using a real test-runner for "Nix" tests?

[Christian Theune]

Hi,

I hacked a little bit on Nix itself a while ago and I was having a hard time 
interacting with the test runner.

Is there interest in a contribution to get a “real” test runner with 
capabilities? I experimented a bit and managed to get
the tests running with a simplish plugin for “pytest” which is my preferred 
test runner.

The good things that would come out of that would be:

* structured output
* not having to manually register tests
* selective runs of individual tests (by name, only ones that failed recently, 
…)
* maybe move towards a more structured approach of managing shared setups
* syntax check the test scripts explicitly

My initial setup was pretty simple:

* adding the existing “pytest” package as a build dependency
* building a basic plugin for “non-python” support (this needs some polishing 
and I’d be happy to)
* renaming the test files to get picked up by the default discovery

The output for a good run now looks like this (not running all tests as I’m 
still fixing some):



So - specifically asking Eelco here - am I stepping on someones toes here? Is 
this interesting to you? Annoying?

I’d be happy to polish this and provide a pull request.

Cheers,
Christian

PS: make installcheck still works with this.

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Configure WiFi networks for NetworkManager in configuration.nix?

[Mateusz Czaplinski]

The `mode = "0400"` approach seems to work indeed, thanks! And just as you
advised, the secret is then world-readable in /nix/store/*-etc/... and in
/etc/nixos/configuration.nix anyway. I see the same issue was discussed in
the aforementioned #12015 (
https://github.com/NixOS/nixpkgs/pull/12015#discussion-diff-48864628), but
it was apparently stepped over and accepted for the time being. Personally,
I'm inclined to add some comment / "SECURITY WARNING" to both the manual
and the option description in my forthcoming PR. That said, I'm sure
interested in how /etc/shadow works if it could possibly be helpful here.

As to other aspects, currently I'm reusing the
"networking.wireless.networks" property from #12015 to build the simple
WiFi config for network-manager. Is that a good way to go (+ modifying the
comments in the config & manual to account for nm), or should I create a
parallel option definition in e.g.
"networking.networkmanager.wirelessNetworks" instead? Or should I go on and
send the PR when ready and move that part of the discussion there?

Thanks,
/Mateusz.

On Thu, Jan 7, 2016 at 12:45 PM, Tomasz Czyż  wrote:

> So, how /etc/shadow file works? I did a quick look and seems it's
> generated by some perl scripts (probably omitting nix store), is that
> correct? Maybe the same way could be used here.
>
> 2016-01-06 15:03 GMT+00:00 Fabian Schmitthenner :
>
>> I think you can use
>>
>> environment.etc."NetworkManager/system-connections/some-file" = {
>>   text = "Text of file";
>>   mode = "0400";
>> }
>>
>> This will copy the file into /etc with appropriate mode at activation
>> time. See also http://nixos.org/nixos/options.html and search for
>> environment.etc for further options.
>>
>> (Of cause other users can still read the original file in the nix store,
>> so the contents would still be reachable for all users).
>>
>> Greetings
>>
>> Fabian
>>
>> On 01/06/2016 02:26 PM, Vladimír Čunát wrote:
>> > On 01/06/2016 12:52 AM, Mateusz Czaplinski wrote:
>> >> NetworkManager expects to have network definitions as chmod 400 files
>> in
>> >> /etc/NetworkManager/system-connections/ IIRC.
>> >
>> > Files in nix store can't be chmod 400.
>> >
>> > --Vladimir
>> >
>> >
>> >
>> >
>> > ___
>> > 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
>>
>>
>
>
> --
> Tomasz Czyż
>
> ___
> 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] Perl -> C++

[Tomasz Czyż]

<:)>
Let's make each script a REST API in any language we want!


2016-01-07 3:26 GMT+00:00 Jakob Gillich :

> > I think there are few enough people who contribute to the nix repo as it
> is now.
>
> That is actually an argument in favor of a rewrite, C++ is not very
> popular in the Linux community. Contributing to Nix will become a lot
> more attractive when it's written in a language that people actually
> enjoy using. At least that's how I personally feel about it, I'm just
> not interested in doing any C++ anymore.
>
> On Wed, Jan 6, 2016, at 09:26 PM, Vladimír Čunát wrote:
> > On 01/06/2016 06:36 PM, stewart mackenzie wrote:
> > > Shall we start defining the nix language?
> >
> > None of the perl stuff deals directly with the nix language, so that
> > seems rather a much independent issue. Personally, I think there are few
> > enough people who contribute to the nix repo as it is now. Do you think
> > starting another implementation would help the quality or something
> > else? Even in a horizon of up to several years?
> >
> > --Vladimir
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> > Email had 1 attachment:
> > + smime.p7s
> >   5k (application/pkcs7-signature)
> ___
> 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] Flattening pkgs tree in nixpkgs/pkgs

[Jakob Gillich]

I agree that the current folder structure is a mess. There is a severe
lack of structure, often there are further category-folders in a folder
with packages (like misc/, misc/themes/).

FreeBSD has categories at the root level, everything below are packages:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-categories.html[1]


Maybe this model could work for us, too?


They also have virtual categories for things like gnome; if we implement
something similar, that would allow maintainers of larger package sets
(@lethalman) to work as usual.

On Fri, Jan 8, 2016, at 01:04 AM, Tomasz Czyż wrote:
> After playing for a while with a nixpkgs repo I have impression that
> categories/directories are just waste of time.
>
> * Have to be maintained
> * Harder to find things
> * Lack of any package manager which tells about it
>
> Each time I want to find a package name I do
> * find -name '*name*' or use github search to locate files in repo.
>
> From maintaining perspective:
>
> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
> 1 - backup 2 - inferno 2 - search 3 - gis 4 - display-managers 10
> - altcoins 11 - science 11 - taxes 20 - virtualization 25 - kde-apps-
> 15.12 27 - office 41 - version-management 41 - window-managers 42
> - networking 59 - video 60 - editors 85 - graphics 186 - audio
> 224 - misc
>
> Do you see that? It's hard to define all those categories levels, some
> of directories have subdirectories (like applications) other not
> (servers). It's hard to follow. Most people know the name of the
> software, if not, they probably use google to find it, not using
> categories.
>
> Let's make the layout more clear, more accessible and easy to follow.
>
> What do you think about moving all packages into flat namespace?
>
> Let's say you have
>
> pkgs/package1/default.nix pkgs/package2/default.nix
>
> or even better:
>
> pkgs/my-package.nix pkgs/gcc.nix pkgs/gcc-5.0.nix
>
> then, you can autogenerate top-level.pkgs
>
> I'm happy to help implementing that.
> _
> nix-dev mailing list nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



Links:

  1. https://freshports.org/categories.php
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Jakob Gillich]

Somehow Fastmail didn't actually replace the link, but only the link text :(. I 
wanted to link to: 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-categories.html[1]


On Fri, Jan 8, 2016, at 03:48 AM, Jakob Gillich wrote:
> I agree that the current folder structure is a mess. There is a severe
> lack of structure, often there are further category-folders in a
> folder with packages (like misc/, misc/themes/).
>
> FreeBSD has categories at the root level, everything below are
> packages:
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-categories.html[2]
>
> Maybe this model could work for us, too?
>
> They also have virtual categories for things like gnome; if we
> implement something similar, that would allow maintainers of larger
> package sets (@lethalman) to work as usual.
>
> On Fri, Jan 8, 2016, at 01:04 AM, Tomasz Czyż wrote:
>> After playing for a while with a nixpkgs repo I have impression that
>> categories/directories are just waste of time.
>>
>> * Have to be maintained
>> * Harder to find things
>> * Lack of any package manager which tells about it
>>
>> Each time I want to find a package name I do
>> * find -name '*name*' or use github search to locate files in repo.
>>
>> From maintaining perspective:
>>
>> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n
>> 1 - backup 2 - inferno 2 - search 3 - gis 4 - display-managers 10
>> - altcoins 11 - science 11 - taxes 20 - virtualization 25 - kde-apps-
>> 15.12 27 - office 41 - version-management 41 - window-managers 42
>> - networking 59 - video 60 - editors 85 - graphics 186 - audio
>> 224 - misc
>>
>> Do you see that? It's hard to define all those categories levels,
>> some of directories have subdirectories (like applications) other not
>> (servers). It's hard to follow. Most people know the name of the
>> software, if not, they probably use google to find it, not using
>> categories.
>>
>> Let's make the layout more clear, more accessible and easy to follow.
>>
>> What do you think about moving all packages into flat namespace?
>>
>> Let's say you have
>>
>> pkgs/package1/default.nix pkgs/package2/default.nix
>>
>> or even better:
>>
>> pkgs/my-package.nix pkgs/gcc.nix pkgs/gcc-5.0.nix
>>
>> then, you can autogenerate top-level.pkgs
>>
>> I'm happy to help implementing that.
>> _
>> 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



Links:

  1. https://freshports.org/categories.php
  2. https://freshports.org/categories.php
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 6:56 PM, Tomasz Czyż  wrote:

>
>
> 2016-01-08 1:28 GMT+00:00 Mathnerd314 :
>
>> Hosting seems like a good index but there might be something else (month
>> project was founded?).
>>
> wow :-) Maybe first letter?
>

Yeah, I guess alphabetical is OK. But clicking on single letters is
s-l-o-w. So 2-letter prefixes.

1000 websites, 676 2-letter prefixes, and 1000 packages for each prefix,
runs to 67600 packages.

npm is the largest package repo currently, with 223942 packages and growth
of 335/day; so we'd run out of space in ~4 years and have to move to 3
levels.
On the other hand, most of their packages are garbage like "Peter is
awesome": https://github.com/peterdemartini/peter/blob/master/index.js; I
don't think it's worth packaging any significant fraction of npm for nix.

So the scheme (host/pa/package) seems reasonable.

The other reason I like using hosting as the first level is that it makes
writing update-crawlers easier.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Tomasz Czyż]

As Mathnerd314 said, filesystem layout != attribute layout. This should
still work as right now.

2016-01-08 1:39 GMT+00:00 Jookia <166...@gmail.com>:

> On Thu, Jan 07, 2016 at 06:29:35PM -0700, Mathnerd314 wrote:
> > On Thu, Jan 7, 2016 at 6:25 PM, Jookia <166...@gmail.com> wrote:
> >
> > > On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote:
> > > > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy :
> > > > Still don't see the value in it. I would just prefix them with
> > > > haskellPackages-, pythonPackages-.
> > >
> > > How would we do something like 'buildInputs = with pythonPackages;
> > > [pycrypto]; '
> > > with that kind of system? I imagine things would get very verbose very
> > > quickly.
> > >
> >
> > We would still have all-packages.nix, so the attribute paths would not
> > change.
> >
> > -- Mathnerd314
>
> Would this still work with conflicting namespaces, such as Python3Packages?
>



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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Jookia]

On Thu, Jan 07, 2016 at 06:29:35PM -0700, Mathnerd314 wrote:
> On Thu, Jan 7, 2016 at 6:25 PM, Jookia <166...@gmail.com> wrote:
> 
> > On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote:
> > > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy :
> > > Still don't see the value in it. I would just prefix them with
> > > haskellPackages-, pythonPackages-.
> >
> > How would we do something like 'buildInputs = with pythonPackages;
> > [pycrypto]; '
> > with that kind of system? I imagine things would get very verbose very
> > quickly.
> >
> 
> We would still have all-packages.nix, so the attribute paths would not
> change.
> 
> -- Mathnerd314

Would this still work with conflicting namespaces, such as Python3Packages?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Tomasz Czyż]

2016-01-08 1:28 GMT+00:00 Mathnerd314 :

> On Thu, Jan 7, 2016 at 5:44 PM, Tomasz Czyż  wrote:
>
>> 2016-01-08 0:37 GMT+00:00 Mathnerd314 :
>>
>>>
>>> I would suggest doing it by hosting site / provider: all KDE packages in
>>> one directory, all GNOME in another, GNU in a third, SourceForge in a
>>> fourth, Kernel.org in a fifth, etc., with a final "misc" directory for
>>> one-package sites.
>>>
>> Looks like good way, but not sure about few things. So github.com whould
>> be another provider?
>> Seems like haskellPackages, pythonPackages, *Packages could follow that
>> rule if we treat lang-repos as providers.
>>
> Yeah, language specific stuff should be their own directories.
> GitHub/SF/etc. are catch-alls; in theory there could be 1000's of projects
> from them, but in practice it seems that most of the projects on there are
> dead, abandoned, or mirrored somewhere else.
>
> The goal is to have a unique location for each package, so that two people
> don't package the same thing twice (which has already happened a few times
> with our current structure).
>
Didn't see that yet, but looks like another good reason to make some
changes around that.


> Hosting seems like a good index but there might be something else (month
> project was founded?).
>
wow :-) Maybe first letter?

>
> Search, nix-env, and command-not-found remain the best way of finding
>>> packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS.
>>>
>> Sorry I was not precise. The problem is to locate program nix file, not
>> the name/attribute.
>>
> Well, once you have the attribute it is usually not too hard to find the
> file by tracing through the code.
>
Exactly, instead of going to the file you have to follow/trace the code.

>
> And some packages are spread across multiple files, e.g. kde4.okular has
> the source hash in pkgs/desktops/kde-4.14/kde-package/4.14.3.nix, the
> description in pkgs/desktops/kde-4.14/kdegraphics/okular.nix, and the glue
> code in pkgs/desktops/kde-4.14/kde-package/default.nix. Keeping all the
> relevant files in one directory seems like the most one could ask for.
>
:-)

>
>
> -- Mathnerd314
>



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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 7:48 PM, Jakob Gillich  wrote:

> I agree that the current folder structure is a mess. There is a severe
> lack of structure, often there are further category-folders in a folder
> with packages (like misc/, misc/themes/).
>
> FreeBSD has categories at the root level, everything below are packages:
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-categories.html
> 
>
> Maybe this model could work for us, too?
>

That has 5338 packages in the devel/ folder. I don't think it works.

Gentoo has a tighter category tree, but they too have run into the 1000
files limit:
https://github.com/gentoo-haskell/gentoo-haskell/tree/master/dev-haskell

I'm thinking haskell/<2-letter prefix> is the way to go, if we needed a
separate file for each package. But the current giant-file system is fine
(other than that GitHub doesn't index it).

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Jakob Gillich]

Oh I never said we should take the same categories, just that
/ is a sane structure. devel for example could be devel-
python, devel-ruby etc, just like the current langPackages.


On Fri, Jan 8, 2016, at 04:35 AM, Mathnerd314 wrote:
> On Thu, Jan 7, 2016 at 7:48 PM, Jakob Gillich
>  wrote:
>> __
>> I agree that the current folder structure is a mess. There is a
>> severe lack of structure, often there are further category-folders in
>> a folder with packages (like misc/, misc/themes/).
>>
>> FreeBSD has categories at the root level, everything below are
>> packages:
>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-categories.html[1]
>>
>> Maybe this model could work for us, too?
>
> That has 5338 packages in the devel/ folder. I don't think it works.
> Gentoo has a tighter category tree, but they too have run into the
> 1000 files limit:
> https://github.com/gentoo-haskell/gentoo-haskell/tree/master/dev-haskell
> I'm thinking haskell/<2-letter prefix> is the way to go, if we needed
> a separate file for each package. But the current giant-file system is
> fine (other than that GitHub doesn't index it).
>
> -- Mathnerd314



Links:

  1. https://freshports.org/categories.php
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[jeaye]

I'm not a fan of this at all, for a few reasons.

>Each time I want to find a package name I do
>* find -name '*name*'
>or use github search to locate files in repo.

Or you can use https://nixos.org/nixos/packages.html which also links
directly to the Nix expression, lists the maintainers, home page, and
even gives a command you can copy for installing imperatively.

The categorization may not be ideal, currently, but I absolutely
support categorization of all packages.

>* Have to be maintained
>* Harder to find things
>* Lack of any package manager which tells about it

It helps fit the directory limitations imposed by Github, sure, and I'd
argue that it makes packages *easier to find*. If you know a package's
name, use the link above, or find(1), or Github. If you don't know a
package's name, but you know what it does, then the categories are very
helpful. Extending out of just nixpkgs into NixOS modules, we can see
just how helpful this becomes:

https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/services/security

Say I want to see what NixOS provides for tightening up my machine.
There's a category just for it and games, networking, monitoring, etc.
This is priceless.

I'd support a rework of the categories to be easier to navigate, but
that would likely result in *more* categories, not fewer.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Christian Theune]

Hi,

same here. I’ve also been a long-time user of Gentoo and found their category 
model quite nice to use.

Obviously the model will never be perfect, but that isn’t an argument in favor 
of abandoning any structure at all.

Christian

> On 07 Jan 2016, at 23:33, jeaye  wrote:
> 
> I'm not a fan of this at all, for a few reasons.
> 
>>   Each time I want to find a package name I do
>>   * find -name '*name*'
>>   or use github search to locate files in repo.
> 
> Or you can use https://nixos.org/nixos/packages.html which also links
> directly to the Nix expression, lists the maintainers, home page, and
> even gives a command you can copy for installing imperatively.
> 
> The categorization may not be ideal, currently, but I absolutely
> support categorization of all packages.
> 
>>   * Have to be maintained
>>   * Harder to find things
>>   * Lack of any package manager which tells about it
> 
> It helps fit the directory limitations imposed by Github, sure, and I'd
> argue that it makes packages *easier to find*. If you know a package's
> name, use the link above, or find(1), or Github. If you don't know a
> package's name, but you know what it does, then the categories are very
> helpful. Extending out of just nixpkgs into NixOS modules, we can see
> just how helpful this becomes:
> 
> https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/services/security
> 
> Say I want to see what NixOS provides for tightening up my machine.
> There's a category just for it and games, networking, monitoring, etc.
> This is priceless.
> 
> I'd support a rework of the categories to be easier to navigate, but
> that would likely result in *more* categories, not fewer.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev