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

[Roger Qiu]

+1 on the meta tags concept if we had a new nix tool that wrapped around
find or used a cached index that could show all packages related to a
particular tag. The cached index could be auto generated on each release or
each commit? Or just generated at installation when a user installs Nix.

Committing new tags can be constrained using pull-request bots that check
against an existing index of tags.

Browsing the nixpkgs directory is a user experience issue for me.
On 11/01/2016 6:32 AM, "Bjørn Forsman"  wrote:

> On 10 January 2016 at 20:20, Spencer Whitt  wrote:
> > -1 on the meta tags approach.
> >
> > 1) Resolving meta tags would require evaluating all of nixpkgs, which we
> > should definitely be moving away from
>
> If eval is too slow we "just" need to implement caching.
>
> (Disclaimer: I'm +1 on meta.tags)
>
> - Bjørn
> ___
> 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

[ikrek vagyunk]

dear fellow nixers,

i  followed this discussion and would like to propose (the already
proposed) way of sorting packages alphabetically and then add some
meta-tags. every package should be in a directory, just like today, with
default.nix and all other files needed for that exact package.

pros:
- would be mostly just automatically moving the current package set around
and adding meta-tags derived from the current directory structure
- all-packages.nix can invoke any package by doing:
  callPackage name {whatever options you want};
- if you add a new package, you instantly know where to put it
- if we would break the 1000 files github limit - or any other reasonable
directory-size limit - we easily can create subdirectories and move the
files accordingly (without any effort)
  /pkgs/a/ -> /pkgs/a and /pkgs/a/a_ (where underscore represents the most
used second character in /pkgs/a and all packages with that prefix could be
moved automatically - note: all-packages.nix wouldn't need to change)
- we would need some new meta-attributes (and they would be nice, i think -
querying for any kind of remote shell that is written in haskell or python
would be sth like: nix-query shell AND server AND (haskell OR python))
  attributes would be: meta.languages, meta.categories,...

cons:
- possible recompilation-issues whenever we move packages to subdirectories
- changes to callPackage/... may be necessary, if we don't want to manually
write the directories
- gnome/kde/haskell/... packages would be scattered around

even though i'm not as good with nix/nixos internals, i believe this is the
easiest way to manage things - correct me if i'm wrong (also add anything,
if you think i'm right, but the proposal is not clever enough ;))


anyway: keep up the good work ;)
regards, ikervagyok

p.s.: about users being capable of reading/writing nix-files: i convinced
three people to use nixos, none of them really use it though - so from my
position it seems like every real user is very capable - and we don't need
to worry much about non-nix-file-reading users...
___
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

[zimbatm]

Okay, now we just need *someone* to implement a proof of concept :p

On Sun, 10 Jan 2016 at 11:13 ikrek vagyunk  wrote:

> dear fellow nixers,
>
> i  followed this discussion and would like to propose (the already
> proposed) way of sorting packages alphabetically and then add some
> meta-tags. every package should be in a directory, just like today, with
> default.nix and all other files needed for that exact package.
>
> pros:
> - would be mostly just automatically moving the current package set around
> and adding meta-tags derived from the current directory structure
> - all-packages.nix can invoke any package by doing:
>   callPackage name {whatever options you want};
> - if you add a new package, you instantly know where to put it
> - if we would break the 1000 files github limit - or any other reasonable
> directory-size limit - we easily can create subdirectories and move the
> files accordingly (without any effort)
>   /pkgs/a/ -> /pkgs/a and /pkgs/a/a_ (where underscore represents the most
> used second character in /pkgs/a and all packages with that prefix could be
> moved automatically - note: all-packages.nix wouldn't need to change)
> - we would need some new meta-attributes (and they would be nice, i think
> - querying for any kind of remote shell that is written in haskell or
> python would be sth like: nix-query shell AND server AND (haskell OR
> python))
>   attributes would be: meta.languages, meta.categories,...
>
> cons:
> - possible recompilation-issues whenever we move packages to subdirectories
> - changes to callPackage/... may be necessary, if we don't want to
> manually write the directories
> - gnome/kde/haskell/... packages would be scattered around
>
> even though i'm not as good with nix/nixos internals, i believe this is
> the easiest way to manage things - correct me if i'm wrong (also add
> anything, if you think i'm right, but the proposal is not clever enough ;))
>
>
> anyway: keep up the good work ;)
> regards, ikervagyok
>
> p.s.: about users being capable of reading/writing nix-files: i convinced
> three people to use nixos, none of them really use it though - so from my
> position it seems like every real user is very capable - and we don't need
> to worry much about non-nix-file-reading users...
> ___
> 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

[Bjørn Forsman]

On 10 January 2016 at 20:20, Spencer Whitt  wrote:
> -1 on the meta tags approach.
>
> 1) Resolving meta tags would require evaluating all of nixpkgs, which we
> should definitely be moving away from

If eval is too slow we "just" need to implement caching.

(Disclaimer: I'm +1 on meta.tags)

- Bjørn
___
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

[Spencer Whitt]

-1 on the meta tags approach.

1) Resolving meta tags would require evaluating all of nixpkgs, which we
should definitely be moving away from
2) Meta tags can be easily misspelled without being easily detected. Even
meta.licenses and meta.platforms are frequently committed while misspelled,
leading to evaluation issues...
3) Due to the flexibility of tags, they are more difficult to manage than
directories.
4) Tags do not solve the maintenance issues raised by Luca. A maintainer
may want packages to be located in the same directory for ease of
maintenance, but with tags they're scattered, albeit tagged.

If you flatten the package hierarchy, you still need to use find/grep to
locate your package. That's no better than using find/grep to locate your
package today. I see little benefit to any of the changes proposed here and
significant cost in merge conflicts and churn.

On Sun, Jan 10, 2016 at 7:24 AM, zimbatm  wrote:

> Okay, now we just need *someone* to implement a proof of concept :p
>
> On Sun, 10 Jan 2016 at 11:13 ikrek vagyunk  wrote:
>
>> dear fellow nixers,
>>
>> i  followed this discussion and would like to propose (the already
>> proposed) way of sorting packages alphabetically and then add some
>> meta-tags. every package should be in a directory, just like today, with
>> default.nix and all other files needed for that exact package.
>>
>> pros:
>> - would be mostly just automatically moving the current package set
>> around and adding meta-tags derived from the current directory structure
>> - all-packages.nix can invoke any package by doing:
>>   callPackage name {whatever options you want};
>> - if you add a new package, you instantly know where to put it
>> - if we would break the 1000 files github limit - or any other reasonable
>> directory-size limit - we easily can create subdirectories and move the
>> files accordingly (without any effort)
>>   /pkgs/a/ -> /pkgs/a and /pkgs/a/a_ (where underscore represents the
>> most used second character in /pkgs/a and all packages with that prefix
>> could be moved automatically - note: all-packages.nix wouldn't need to
>> change)
>> - we would need some new meta-attributes (and they would be nice, i think
>> - querying for any kind of remote shell that is written in haskell or
>> python would be sth like: nix-query shell AND server AND (haskell OR
>> python))
>>   attributes would be: meta.languages, meta.categories,...
>>
>> cons:
>> - possible recompilation-issues whenever we move packages to
>> subdirectories
>> - changes to callPackage/... may be necessary, if we don't want to
>> manually write the directories
>> - gnome/kde/haskell/... packages would be scattered around
>>
>> even though i'm not as good with nix/nixos internals, i believe this is
>> the easiest way to manage things - correct me if i'm wrong (also add
>> anything, if you think i'm right, but the proposal is not clever enough ;))
>>
>>
>> anyway: keep up the good work ;)
>> regards, ikervagyok
>>
>> p.s.: about users being capable of reading/writing nix-files: i convinced
>> three people to use nixos, none of them really use it though - so from my
>> position it seems like every real user is very capable - and we don't need
>> to worry much about non-nix-file-reading users...
>> ___
>> 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
>
>
___
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-09 20:41 GMT+00:00 Matthias Beyer :

> On 08-01-2016 01:32:34, Profpatsch wrote:
> >
> > Now the problem is: Who has enough time to refactor everything? :)
> >
>
> +1 on this. I think that flattening the file tree for nixpkgs/pkgs is just
> a
> waste of time.
>
> As the OP of this thread says, he has to use `find` all the time. Now
> what?

Now I try to change it.

> We
> all have and it works perfectly fine for all of us.

I explicitly excluded myself from the "all" group so I assume you cannot
use "all" here, and according to that discussion looks like there is few
people who have different opinions about current situation.

> Why changing (or even
> debating) about things which _work_ and where changes do not improve the
> experience of the end-user?
>
Sure, please, help Debian project :-)

>
> I mean, come one, nixos is not a big community who has time to argue about
> infrastructure which does change (note: I don't use the term "improve"
> here)
> something for the maintainers but doesn't change anything for the end user!
>
Is anyone here who knows any nix user which do not read nix files and is
only "end-user"?
For me personally as "end-user" the file structure is part of user
experience. Same as nix command line interface.


> User experience is what comes first, and this proposal doesn't alter user
> experience (neither improve nor worsen) at all. So why focusing on
> something
> like this? Why debating about internal infrastructure changes while the
> end-user
> is faced with hydra not building for weeks or while there are packages out
> there
> which do not run because of unmet dependencies,... I could possibly go on.
> I
> don't want to start a conversation on the latter two points in here, but I
> guess
> you see what I mean.
>
I as wrote, for me it IS user-experience. And I'm not sure what the
projejct short/long term goals are but I think most users are
developers/admins who write nix files anyway.

Please define what for you is real end-user of nixos and please give some
examples what are cases worth to waste time for you.

btw, why some people argue about others people time? There is bunch of
people want to make some positive change and they want to spent some time
on that (whatever the change is). I wrote that I would like to help with
that (or maybe even implement that if I have enough knowledge), please if
you think it's waste of time, propose something else to change and make it
happen.


> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Proudly sent with mutt.
> Happily signed with gnupg.
>
> ___
> 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

[Matthias Beyer]

On 08-01-2016 01:32:34, Profpatsch wrote:
> 
> Now the problem is: Who has enough time to refactor everything? :)
> 

+1 on this. I think that flattening the file tree for nixpkgs/pkgs is just a
waste of time.

As the OP of this thread says, he has to use `find` all the time. Now what? We
all have and it works perfectly fine for all of us. Why changing (or even
debating) about things which _work_ and where changes do not improve the
experience of the end-user?

I mean, come one, nixos is not a big community who has time to argue about
infrastructure which does change (note: I don't use the term "improve" here)
something for the maintainers but doesn't change anything for the end user!
User experience is what comes first, and this proposal doesn't alter user
experience (neither improve nor worsen) at all. So why focusing on something
like this? Why debating about internal infrastructure changes while the end-user
is faced with hydra not building for weeks or while there are packages out there
which do not run because of unmet dependencies,... I could possibly go on. I
don't want to start a conversation on the latter two points in here, but I guess
you see what I mean.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
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]

On 16-01-08 08:53am, Daniel Peebles wrote:
>  and that
> all-packages.nix should be abolished (use builtins.readDir by default and a
> manual overrides file where necessary)

Strong -1 on this one.

#1: Explicit is better than implicit

Things will get very ugly.

-- 
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

[Profpatsch]

On 16-01-08 10:16pm, Tomasz Czyż wrote:
> 2016-01-08 14:58 GMT+00:00 Vladimír Čunát :
> > The largest problem I see for categorization is ambiguity (mentioned
> > already). The "categories" will always overlap nontrivially, so we would
> > better track such information in a different way than directory
> > structure, e.g. meta.tags = [ "foo" "bar" "baz" ]; (perhaps even
> > hierarchical tags).
>
> +1

Tags are generally a better solution for most categorization problems.
But it’s not trivial to get a working system where consistens tags are
used.

-- 
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

[Jonathan Glines]

2016/01/09 午前10:36 "Profpatsch" :
>
> On 16-01-08 08:53am, Daniel Peebles wrote:
> >  and that
> > all-packages.nix should be abolished (use builtins.readDir by default
and a
> > manual overrides file where necessary)
>
> Strong -1 on this one.
>
> #1: Explicit is better than implicit
>
> Things will get very ugly.

On the other hand, don't repeat yourself is an important principle; the
current all-packages.nix is already pretty ugly. Any build problems would
be handled by a (much shorter) override or blacklist.

Anyway, devil's advocate +1 on this. I like it, but it's all bikeshed
unless someone makes a proof of concept.
___
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]

On 16-01-09 10:56am, Jonathan Glines wrote:
> 2016/01/09 午前10:36 "Profpatsch" :
> >
> > On 16-01-08 08:53am, Daniel Peebles wrote:
> > >  and that
> > > all-packages.nix should be abolished (use builtins.readDir by default
> and a
> > > manual overrides file where necessary)
> >
> > Strong -1 on this one.
> >
> > #1: Explicit is better than implicit
> >
> > Things will get very ugly.
> 
> On the other hand, don't repeat yourself is an important principle; the
> current all-packages.nix is already pretty ugly. Any build problems would
> be handled by a (much shorter) override or blacklist.

I must disagree very strongly.
The function and its invocation are two completely different things
that should not be confused.

In this case the invocations in all-packages.nix serve two important roles:
1) They create an identifier for the package/packageset
2) They specify which dependencies the package use
The function itself does not encode any of that information.

Also, callPackages already relieves the packager from most of the work.
In fact, one might even argue that callPackages might be too implicit.

-- 
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

[Oliver Charles]

On Fri, Jan 8, 2016 at 3:53 PM Domen Kožar  wrote:

> Going for attribute set names is hard, since we have many aliases.
>
> We had a discussion about this at NixCon (I think Oliver Charles has the
> notes).
>

Yep, I lead that sesison but unfortunately haven't had the bandwidth to
start the discussion (as evidinced by the amount of conversation this
thread has already seen!). I'll try and dig my notes out though soon.


- Ollie
___
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 15:55 GMT+00:00 Arseniy Seroka :

> In my opinion we should spend our time and skills to solve more important
> issues and problems.
>
On the other hand I agree with that, on the other I wasted some time
figuring that stuff out and I'll waste more. And as it seems not only me...

Fixing this shouldn't be that hard I think. If we will go to the point
where "top-packages" could be autogenerated or not needed at all (I'm not
sure what plans are about that but probably some duplication could be
limited there), than fixing file layout will not be very time consuming
(imho).



> On 8 Jan 2016 18:53, "Domen Kožar"  wrote:
>
>> Going for attribute set names is hard, since we have many aliases.
>>
>> We had a discussion about this at NixCon (I think Oliver Charles has the
>> notes).
>>
>> In general, the only thing that really matters here is not to waste
>> people time. Currently it's suboptimal, I'd really just be happy if we had
>> flat structure. That does impose problems since it's hard to find a system
>> to categorize software.
>>
>> It's really worth checking out what other package managers do and see who
>> is happy about their structure.
>>
>> On Fri, Jan 8, 2016 at 4:47 PM, zimbatm  wrote:
>>
>>> The issue with naming is that everyone has their opinion.
>>>
>>> Since other smart people have already played the categorization game can
>>> I suggest to restrict the discussion to which *existing* structure we
>>> should adopt ?
>>> There are a lot of big repositories out there: debian, gentoo portage,
>>> archlinux, pkgsrc, ... One of them is bound to work, mostly. The nice
>>> benefit would also be of not having to talk about categorization ever
>>> again, unless the packaged project doesn't exist in the canonical
>>> repository.
>>>
>>> I don't care what structure we chose as long as it's shallower than what
>>> we have right now. Like OP I'm tired of searching for packages and then
>>> entering long paths in my shell.
>>>
>>>
>>> On Fri, 8 Jan 2016 at 15:03 Bjørn Forsman 
>>> wrote:
>>>
 On 8 January 2016 at 15:58, Vladimír Čunát  wrote:
 > Personally, I would make it much flatter and also make it (almost)
 > exactly correspond to our *attribute* hierarchy.

 That's a good idea, I think!

 /Bjørn
 ___
 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
>>>
>>>
>>
>> ___
>> 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

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

[Tomasz Czyż]

2016-01-08 14:58 GMT+00:00 Vladimír Čunát :

> On 01/08/2016 02:53 PM, Daniel Peebles wrote:
> > I think the categories/directories could make more sense than they do
> > today, and that all-packages.nix should be abolished
>
> The largest problem I see for categorization is ambiguity (mentioned
> already). The "categories" will always overlap nontrivially, so we would
> better track such information in a different way than directory
> structure, e.g. meta.tags = [ "foo" "bar" "baz" ]; (perhaps even
> hierarchical tags).
>
+1

>
> Currently a significant portion of our packages is in
> pkgs/development/libraries/ - which is a rather bad category IMO. If I
> didn't use tab-completion, I would've pushed this issue hard long time
> ago already.
>
> Personally, I would make it much flatter and also make it (almost)
> exactly correspond to our *attribute* hierarchy.
>
+100

>
> We had some discussion around this on NixCon. IMO best time to execute
> this will be during release stabilization to minimize cherry-pick
> conflicts due to file renames, but first we need a clear consensus.
>
>
> Vladimir
>
>
>
> ___
> 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

[Luca Bruno]

On Fri, Jan 8, 2016 at 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)
>

I'm ok with flattening that, maybe I wasn't clear.


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

Because I maintain gnome-terminal and I want that in the gnome directory as
it's easier for my way of maintaining those packages.
___
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

[Bjørn Forsman]

On 8 January 2016 at 15:58, Vladimír Čunát  wrote:
> Personally, I would make it much flatter and also make it (almost)
> exactly correspond to our *attribute* hierarchy.

That's a good idea, I think!

/Bjørn
___
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

[Daniel Peebles]

Adding another -1 to flattening all directories. I think the
categories/directories could make more sense than they do today, and that
all-packages.nix should be abolished (use builtins.readDir by default and a
manual overrides file where necessary), but throwing away all structure
because it isn't perfect seems excessive. I personally have found browsing
the folders quite informative, even if sometimes it's unclear where a new
package belongs.


On Fri, Jan 8, 2016 at 5:20 AM, Luca Bruno  wrote:

> On Fri, Jan 8, 2016 at 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)
>>
>
> I'm ok with flattening that, maybe I wasn't clear.
>
>
>> Same for "groups", why gnome-terminal is more gnome and not more terminal?
>>
>
> Because I maintain gnome-terminal and I want that in the gnome directory
> as it's easier for my way of maintaining those packages.
>
>
> ___
> 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

[Vladimír Čunát]

On 01/08/2016 02:53 PM, Daniel Peebles wrote:
> I think the categories/directories could make more sense than they do
> today, and that all-packages.nix should be abolished

The largest problem I see for categorization is ambiguity (mentioned
already). The "categories" will always overlap nontrivially, so we would
better track such information in a different way than directory
structure, e.g. meta.tags = [ "foo" "bar" "baz" ]; (perhaps even
hierarchical tags).

Currently a significant portion of our packages is in
pkgs/development/libraries/ - which is a rather bad category IMO. If I
didn't use tab-completion, I would've pushed this issue hard long time
ago already.

Personally, I would make it much flatter and also make it (almost)
exactly correspond to our *attribute* hierarchy.

We had some discussion around this on NixCon. IMO best time to execute
this will be during release stabilization to minimize cherry-pick
conflicts due to file renames, but first we need a clear consensus.


Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Domen Kožar]

Going for attribute set names is hard, since we have many aliases.

We had a discussion about this at NixCon (I think Oliver Charles has the
notes).

In general, the only thing that really matters here is not to waste people
time. Currently it's suboptimal, I'd really just be happy if we had flat
structure. That does impose problems since it's hard to find a system to
categorize software.

It's really worth checking out what other package managers do and see who
is happy about their structure.

On Fri, Jan 8, 2016 at 4:47 PM, zimbatm  wrote:

> The issue with naming is that everyone has their opinion.
>
> Since other smart people have already played the categorization game can I
> suggest to restrict the discussion to which *existing* structure we should
> adopt ?
> There are a lot of big repositories out there: debian, gentoo portage,
> archlinux, pkgsrc, ... One of them is bound to work, mostly. The nice
> benefit would also be of not having to talk about categorization ever
> again, unless the packaged project doesn't exist in the canonical
> repository.
>
> I don't care what structure we chose as long as it's shallower than what
> we have right now. Like OP I'm tired of searching for packages and then
> entering long paths in my shell.
>
>
> On Fri, 8 Jan 2016 at 15:03 Bjørn Forsman  wrote:
>
>> On 8 January 2016 at 15:58, Vladimír Čunát  wrote:
>> > Personally, I would make it much flatter and also make it (almost)
>> > exactly correspond to our *attribute* hierarchy.
>>
>> That's a good idea, I think!
>>
>> /Bjørn
>> ___
>> 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
>
>
___
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

[zimbatm]

The issue with naming is that everyone has their opinion.

Since other smart people have already played the categorization game can I
suggest to restrict the discussion to which *existing* structure we should
adopt ?
There are a lot of big repositories out there: debian, gentoo portage,
archlinux, pkgsrc, ... One of them is bound to work, mostly. The nice
benefit would also be of not having to talk about categorization ever
again, unless the packaged project doesn't exist in the canonical
repository.

I don't care what structure we chose as long as it's shallower than what we
have right now. Like OP I'm tired of searching for packages and then
entering long paths in my shell.


On Fri, 8 Jan 2016 at 15:03 Bjørn Forsman  wrote:

> On 8 January 2016 at 15:58, Vladimír Čunát  wrote:
> > Personally, I would make it much flatter and also make it (almost)
> > exactly correspond to our *attribute* hierarchy.
>
> That's a good idea, I think!
>
> /Bjørn
> ___
> 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

[Arseniy Seroka]

In my opinion we should spend our time and skills to solve more important
issues and problems.
On 8 Jan 2016 18:53, "Domen Kožar"  wrote:

> Going for attribute set names is hard, since we have many aliases.
>
> We had a discussion about this at NixCon (I think Oliver Charles has the
> notes).
>
> In general, the only thing that really matters here is not to waste people
> time. Currently it's suboptimal, I'd really just be happy if we had flat
> structure. That does impose problems since it's hard to find a system to
> categorize software.
>
> It's really worth checking out what other package managers do and see who
> is happy about their structure.
>
> On Fri, Jan 8, 2016 at 4:47 PM, zimbatm  wrote:
>
>> The issue with naming is that everyone has their opinion.
>>
>> Since other smart people have already played the categorization game can
>> I suggest to restrict the discussion to which *existing* structure we
>> should adopt ?
>> There are a lot of big repositories out there: debian, gentoo portage,
>> archlinux, pkgsrc, ... One of them is bound to work, mostly. The nice
>> benefit would also be of not having to talk about categorization ever
>> again, unless the packaged project doesn't exist in the canonical
>> repository.
>>
>> I don't care what structure we chose as long as it's shallower than what
>> we have right now. Like OP I'm tired of searching for packages and then
>> entering long paths in my shell.
>>
>>
>> On Fri, 8 Jan 2016 at 15:03 Bjørn Forsman 
>> wrote:
>>
>>> On 8 January 2016 at 15:58, Vladimír Čunát  wrote:
>>> > Personally, I would make it much flatter and also make it (almost)
>>> > exactly correspond to our *attribute* hierarchy.
>>>
>>> That's a good idea, I think!
>>>
>>> /Bjørn
>>> ___
>>> 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
>>
>>
>
> ___
> 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

[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] 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] 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